Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt

From: Henning Rogge <[email-masked]>
Date: Mon, 3 Dec 2012 14:25:43 +0100

Hi Charly,

I tried to do a first DYMO review based on your new draft. I did not 
looked into the protocol workings itself, but I still hope you will find 
the input useful.

 > Mobile Ad hoc Networks Working Group                C. Perkins
 > Internet-Draft                                       Futurewei
 > Intended status: Standards Track                   I. Chakeres
 > Expires: June 4, 2013                                   CenGen

Page 5:

 > AODVv2 Sequence Number (SeqNum)
 > An AODVv2 Sequence Number is an unsigned integer maintained by
 > each AODVv2 router.  This sequence number guarantees the temporal
 > order of routing information to maintain loop-free routes.  The
 > value zero (0) is reserved to indicate that the SeqNum for a
 > destination address is unknown.

I still do not like this special value.

 > Handling Router (HandlingRtr)
 > HandlingRtr denotes the AODVv2 router handling an AODVv2 message.

Do you really need the "HandlingRtr" abbreviation? It complicates the 
text and does not shorten it that much.

Page 6:

 > Originating Node (OrigNode)

 > Originating Router (OrigRtr)

See comment to "HandlingRtr".

 > Router Client
 > An AODVv2 router may be configured with a list of other IP
 > addresses and networks which correspond to other non-router nodes
 > which require the services of the AODVv2 router for route
 > discovery and maintenance.  An AODVv2 is always its own client, so
 > that the list of client IP addresses is never empty.
 >
 > Sequence Number (SeqNum)
 > Same as AODVv2 Sequence Number.

If this is the same, why do you need "AODVv2 Sequence Number" ? Just use 
"Sequence Number"

 > Target Node (TargNode)
 > The Target Node denotes the node for which a route is needed.
 >
 > Target Router (TargRtr)
 > The TargetRtr denotes the AODVv2 router which serves TargNode.

TargRtr? TargetRtr? TargetRouter?

Page 8:

 > +--------------------+-------------------------------------------+
 > |      Notation      |    Information Location and/or Meaning    |
 > +--------------------+-------------------------------------------+
 > |   Route[DestAddr]  |    A route table entry towards DestAddr   |
 > | Route[Addr]{field} |       A field in a route table entry      |
 > |         --         |                     --                    |
 > |    RREQ.{field}    |               Field in RREQ               |
 > |    RREP.{field}    |               Field in RREP               |
 > |    RERR.{field}    |               Field in RERR               |

Maybe RREQ{field} to be costistent with the Route notation?

 > |         --         |                     --                    |
 > |       MsgHdr       |         the RFC5444 Message Header        |
 > |       MsgTLV       |           an RFC5444 Message TLV          |
 > |    MetricTypeTLV   |    MetricType MsgTLV for Metric AddrTLV   |
 > |         MAL        |          MsgHdr.<msg-addr-length>         |

Do you really need this abbreviation?

 > |         --         |                     --                    |
 > |       AddrBlk      |          an RFC5444 address block         |
 > |     AddrBlk[1]     |     The first address slot in AddrBlk     |
 > |     AddrBlk[N]     |      The Nth address slot in AddrBlk      |
 > |  AddrBlk[OrigNode] |                 AddrBlk[1]                |
 > |  AddrBlk[TargNode] |                 AddrBlk[2]                |

Using the order of addresses in an address block as protocol semantics 
is a bad idea. Use TLVs attached to the addresses to identify their purpose.

 > |       AddrTLV      |        an RFC5444 address block TLV       |

Is this an address TLV block (a list of TLVs) or an address block TLV (a 
single TLV) ?

The following notation suggests its a TLV block.

 > |     AddrTLV[1]     |         the first item in AddrTLV         |
 > |     AddrTLV[N]     |          the Nth item in AddrTLV          |
 > |  AddrTLV[OrigNode] |                 AddrTLV[1]                |
 > |  AddrTLV[TargNode] |                 AddrTLV[2]                |

Again, using the order of addresses as protocol semantics is a bad idea. 
Use TLVs attached to the addresses to identify their purpose.

 > |     HopCountTLV    |    Metric8 AddrTLV when MetricTypeTLV=3   |

Defining an abbreviation for a TLV that depends on the value of a 
different TLV is confusing.

 > |     Metric8TLV     |              Metric8 AddrTLV              |
 > |      SeqNumTLV     | Sequence Number TLV for AddrBlk addresses |
 > |     RteAddrBlk     |     the main address block in a RteMsg    |

RteMsg ? Less abbreviations!

 > |    RteSeqNumTLV    | Sequence Numbers for RteAddrBlk addresses |
 > |   UnreachAddrBlk   |      Unreachable Node AddrBlk in RERR     |
 > |         --         |                     --                    |
 > |       OrigRtr      |          RREQ Originating Router          |
 > |      OrigNode      |              Originating Node             |
 > |      RREQ_Gen      |     AODVv2 router originating an RREQ     |
 > |      RREP_Gen      |    AODVv2 router responding to an RREQ    |
 > |       RteMsg       |            either RREQ or RREP            |
 > |     RteMsg_Orig    |           Originator of a RteMsg          |
 > |     HandlingRtr    |              Handling Router              |
 > |       TargRtr      |               Target Router               |
 > |      TargNode      |                Target Node                |
 > |   UnreachableNode  |              Unreachable Node             |
 > +--------------------+-------------------------------------------+

Page 10:

 > 5.  Data Structures
 >
 > 5.1.  Route Table Entry
 >
 > The route table entry is a conceptual data structure.
 > Implementations may use any internal representation so long as it
 > provides access to the same information as specified below.
 >
 > Conceptually, a route table entry has the following fields:
 >
 > Route.Address
 > The (host or network) destination address of the node(s)
 > associated with the routing table entry
 >
 > Route.PfxLen

Another confusing abbreviation.
 > The value is the length of the netmask/prefix.  If the value of
 > the Route.PfxLen is nonzero and different than the length of

only if non-zero? How does AODVv2 represents a "full internet" route 
like 0.0.0.0/0 ?

 > addresses in the address family used by the AODVv2 routers, the
 > associated address is a routing prefix, rather than a host
 > address.

Page 12:

 > Timed
 > The expiration of a Timed route is controlled by the
 > Route.ExpirationTime time of the route table entry, not
 > MAX_IDLETIME.  Until that time, a Timed route can be used for
 > forwarding packets.  Afterwards, the route must be Expired (or
 > expunged).
 >
 > The route's state determines the operations that can be performed on
 > the route table entry.  During use, an Active route is maintained
 > continuously by AODVv2 and is considered to remain active as long as
 > it is used at least once during every ACTIVE_INTERVAL.  When a route
 > is no longer Active, it becomes an Idle route.  After a route remains
 > Idle for MAX_IDLETIME, it becomes an Expired route; after that, the
 > route is not used for forwarding, but the sequence number information
 > can be maintained until the destination sequence number has had no
 > updates for MAX_SEQNUM_LIFETIME.  After MAX_SEQNUM_LIFETIME, old
 > sequence number information is considered no longer valuable and the
 > route is expunged.
 >
 > MAX_SEQNUM_LIFETIME is the time after a reboot during which an AODVv2

Is MAX_SEQNUM_LIFETIME different to a "Validity Time" ?

 > router MUST NOT transmit any routing messages.  Thus, if all other
 > AODVv2 routers expunge routes to the rebooted router after that time
 > interval, the rebooted AODVv2 router's sequence number will not be
 > considered stale by any other AODVv2 router in the MANET.
 >
 > When the link to a route's next hop is broken, the route is marked as
 > being Broken, and the route may no longer be used.
 >
 > 5.2.  Bidirectional Connectivity During Route Discovery and Blacklists
 >
 > To avoid repeated failure of Route Discovery, an AODVv2 router
 > (HandlingRtr) handling a RREP message MAY attempt to verify

Another unnecessary abbreviation

Page 13:

 > BlacklistNode
 > The IP address of the node that did not verify bidirectional
 > connectivity.

Blacklist.Node ?

 > BlacklistRmTime
 > The time at which BlacklistNode will be removed from the
 > blacklist.

Blacklist.RemoveTime ?

 > 5.4.  AODVv2 Packet Header Fields and Information Elements
 >
 > In its default mode of operation, AODVv2 uses the UDP port 269
 > [RFC5498] to carry protocol packets.  In addition, IP Protocol Number
 > 138 has been reserved for MANET protocols [RFC5498].  Most AODVv2
 > messages are sent with the IP destination address set to the link-

You mean packets, not messages?

Page 14:

 > manually configured router adjacencies, or in order to improve
 > robustness.
 >
 > The IPv4 TTL (IPv6 Hop Limit) field for all packets containing AODVv2
 > messages is set to 255.  If a packet is received with a value other

I think (if we keep this at all) this should move to "security 
considerations".

 > than 255, any AODVv2 message contained in the packet MUST be
 > disregarded by AODVv2.  This mechanism, known as "The Generalized TTL
 > Security Mechanism" (GTSM) [RFC5082] helps to assure that packets
 > have not traversed any intermediate routers.

I do not agree with this MUST.

 > IP packets containing AODVv2 protocol messages SHOULD be given
 > priority queuing and channel access.
 >
 > AODVv2 messages are transmitted in packets that conform to the packet
 > and message format described in [RFC5444].  Here is a brief
 > description of the format.
 >
 > A packet formatted according to RFC5444 contains zero or more
 > messages.
 >
 > A message contains a message header, message TLV block, and zero
 > or more address blocks.
 >
 > Each address block may also have associated TLV blocks.

"have one associated TLV block" (one per address block).

 > If a packet contains only a single AODVv2 message and no packet TLVs,
 > it need not include a packet-header [RFC5444].

This is wrong and breaks ALL RFC5444 compatibility. You MUST put the 
minimal Packet-Header in front of the first message (which is a single 0 
octet).

 > The length of an
 > address (32 bits for IPv4 and 128 bits for IPv6) inside an AODVv2
 > message is indicated by the msg-addr-length (MAL) in the msg-header,
 > as specified in [RFC5444].
 >
 > When multiple messages are aggregated into a single packet according
 > to RFC 5444 formatting, and the aggregation of messages is also
 > authenticated (e.g., with IPsec), it becomes unfeasible to delete
 > individual messages.

Packet signatures are "link scope" because packets should not be 
forwarded with RFC5444. If you want to forward some/all messages, you 
can generate a new packet signature.

Page 15:

 > An AODVv2 router SHOULD maintain OwnSeqNum in persistent storage.  If
 > an AODVv2 router's OwnSeqNum is lost, it MUST take the following
 > actions to avoid the danger of routing loops.  First, the AODVv2
 > router MUST invalidate all route table entries, by setting
 > Route.Broken for each entry.  Furthermore the AODVv2 router MUST wait
 > for at least MAX_SEQNUM_LIFETIME before transmitting or

MAX_SEQNUM_LIFETIME looks more and more like a typical validity time.

Page 16:

 > Generally, HopCount may still be considered the default metric for
 > use in MANETs, notwithstanding the above objections.  Each metric has
 > to have a Metric Type, and the Metric Type is allocated by IANA as
 > specified in [RFC6551].  Each Route has to include the Metric Type as
 > part of the route table entry for that route.  Hop Count has Metric
 > Type assignment 3.  The Cost of a route using Metric Type 3 is
 > naturally the Hop Count between the router and the destination.  For
 > routes R1 and R2 using Metric Type 3, LoopFree (R1, R2) is TRUE when
 > Cost(R2) <= (Cost(R1) + 1).  The specification of Cost(R) and

Cost(R2) < Cost(R1) ?

 > LoopFree(R1,R2) for metric types other than 3 is beyond the scope of
 > this document.

Could the Cost() function be used locally to calculate the original link 
cost, so that it doesn't need to be considered anymore when receiving 
and processing messages ?

Page 19:

 > o  If RteMsg.VALIDITY_TIME is not included, then
 > Route.ExpirationTime := MAXTIME, otherwise Route.ExpirationTime :=
 > Current_Time + RteMsg.VALIDITY_TIME

How does the VALIDITY_TIME relate to the MAX_SEQNUM_LIFETIME ?

Page 21/22:

 > 7.2.  RteMsg Structure
 >
 > RteMsgs have the following general format:
 >
 > +---------------------------------------------------------------+
 > |                     RFC 5444 Packet Header                    |
 > +---------------------------------------------------------------+

This is not part of the Message.

 > |             RFC 5444 Message Header <msg-hopcount>            |
 > +---------------------------------------------------------------+
 > |    RFC 5444 MsgHdr, opt. DestOnly TLV, opt. MetricTypeTLV     |

I would suggest using an optional Extension Type for the Metric TLV 
instead of the MetricTypeTLV.

 > +---------------------------------------------------------------+
 > |       RteAddrBlk {[1]:=RREQ.OrigNode,[2]:=RREQ.TargNode)}     |
 > +---------------------------------------------------------------+
 > |         RteSeqNumTLV (OrigRtr.Seqnum, TargNode.Seqnum)        |
 > +---------------------------------------------------------------+

Not clear to which addresses these TLVs belong.

 > |              Added Node Address Block (Optional)              |
 > +---------------------------------------------------------------+

A second address block? Couldn't these be inside the first address block 
too?

 > |                Added Node Address TLV (SeqNum)                |
 > +---------------------------------------------------------------+
 > |          Added Node Address TLV (Metric[MetricType])          |
 > +---------------------------------------------------------------+

I am not sure if the diagram above is really helpful understanding what 
a message looks like.

Page 23:

 > 7.3.  RREQ Generation
 >
 > RREQ_Gen generates the RREQ according to the following steps, with
 > order of protocol elements illustrated schematically in Figure 1.
 >
 > 1.  RREQ_Gen MUST increment its OwnSeqNum by one (1) according to the
 > rules specified in Section 5.5.  This assures that all nodes with
 > existing routing information will use RREQ_Gen's new information
 > to update existing routing table information.
 >
 > 2.  OrigNode MUST be a unicast address.  If RREQ_Gen is not OrigNode,
 > then OwnSeqNum will be used as the value of OrigNode.SeqNum. will
 > be used by AODVv2 routers to create a route toward the OrigNode,
 > enabling a RREP from TargRtr, and eventually used for proper
 > forwarding of data packets.
 >
 > 3.  If RREQ_Gen requires that only TargRtr is allowed to generate a
 > RREP, then RREQ_Gen includes the "Destination RREP Only" TLV as
 > part of the RFC 5444 message header.  This also assures that
 > TargRtr increments its sequence number.  Otherwise, intermediate
 > AODVv2 routers MAY respond to the RREQ_Gen's RREQ if they have an
 > valid route to TargNode (see Section 13.2).
 >
 > 4.  msg-hopcount MUST be set to 0.
 >
 > *  This RFC 5444 constraint causes the typical RteMsg payload
 > incur additional enlargement.

There is no constraint in RFC5444 to add this field to a message. Unless 
you plan to use it.

Page 24:

 > 7.  RREQ_Gen adds OrigNode.Addr, its prefix, and the RREQ_Gen.SeqNum
 > (OwnSeqNum) to the RREQ.
 >
 > 8.  If OrigNode.Metric is included it is set to the cost of the route
 > between OrigNode and RREQ_Gen.
 >
 > An example RREQ message format is illustrated in Appendix A.1.
 >
 > 7.4.  RREP Generation
 >
 > An AODVv2 router (TargRtr, called in this section RREP_Gen) generates
 > a RREP in order to provide a route to the Target Node (TargNode) of a
 > RREQ, thus satisfying the routing requirement for packets to flow
 > between OrigNode and TargNode.  This section specifies the generation
 > of an RREP by the RREP_Gen. The basic format of an RREP conforms to
 > the structure for RteMsgs as illustrated in Figure 1.  Optionally,
 > RREP messages may be generated by AODVv2 routers other than TargRtr;
 > this optional message generation is known as "Intermediate RREP"
 > generation, and is specified in Internet Draft [I-D.perkins-irrep].
 > If TargNode is not a unicast IP address the RREP MUST NOT be
 > generated, and processing for the RREQ is complete.
 >
 > Otherwise RREP_Gen generates the RREP as follows:
 >
 > 1.   RREP_Gen first uses the routing information to update its route
 > table entry for OrigNode if necessary as specified in
 > Section 6.2.
 >
 > 2.   RREP_Gen MUST increment its OwnSeqNum by one (1) according to
 > the rules specified in Section 5.5.
 >
 > 3.   RREP.AddrBlk[OrigNode] := RREQ.AddrBlk[OrigNode]
 >
 > 4.   RREP.AddrBlk[TargNode] := RREQ.AddrBlk[TargNode]
 >
 > 5.   RREP.SeqNumTLV[OrigNode] := RREQ.SeqNumTLV[OrigNode]
 >
 > 6.   RREP.SeqNumTLV[TargNode] := OwnSeqNum
 >
 > 7.   If Route[TargNode].PfxLen/8 is equal to the number of bytes in
 > the addresses of the RREQ (4 for IPv4, 16 for IPv6), then no
 > <prefix-length> is included with the iRREP.  Otherwise,
 > RREP.PfxLen[TargNode] := RREQ.PfxLen[TargNode] according to the
 > rules of RFC 5444 AddrBlk encoding.

Isn't this "full prefix length can be skipped" an explicit part of the 
RFC 5444 description? I do not think you need to worry about this here, 
its the choice of the implementation if it want to use 
ahassingle/ahasmulti both 0 or not.

Page 28:

 > 8.3.  RERR Generation
 >
 > An RERR message is generated by a AODVv2 router (in this section,
 > called RERR_Gen) in order to to notify upstream routers that packets
 > cannot be delivered to certain destinations.  An RERR message has the
 > following general structure:
 >
 > +---------------------------------------------------------------+
 > |                     RFC 5444 Packet Header                    |
 > +---------------------------------------------------------------+

Not part of the message.

Page 29:

 > Message Header
 > RFC 5444 MsgHdr may contain the following options:
 >
 > *  <msg-hop-limit>
 >
 > *  <msg-hop-count>
 >
 > *  PktSource MsgTLV

Message-TLVs are not part of the RFC5444 message header.

Page 32:

 > 10.  Simple Internet Attachment
 >
 > Simple Internet attachment means attachment of a stub (i.e., non-
 > transit) network of AODVv2 routers to the Internet via a single
 > Internet AODVv2 router (called IAR).

maybe just call it (Internet) Gateway instead of IAR?

 > As in any Internet-attached network, AODVv2 routers, and their
 > clients, wishing to be reachable from hosts on the Internet MUST have
 > IP addresses within the IAR's routable and topologically correct
 > prefix (e.g. 191.0.2.0/24).
 >
 > The IAR is responsible for generating RREQ messages to find nodes
 > within the MANET on behalf of nodes on the Internet, as well as
 > responding to route requests from the AODVv2 MANET on behalf of the
 > nodes on the Internet.

Its not allowed to have two gateways to the Internet for an AODVv2 MANET?

Page 40:

 > +------------------------+-----------+------------------------------+
 > |          Name          |   Value   |          Description         |
 > +------------------------+-----------+------------------------------+
 > |      MAX_HOPCOUNT      |  20 hops  |   This value MUST be larger  |
 > |                        |           |    than the AODVv2 network   |
 > |                        |           |     diameter.  Otherwise,    |
 > |                        |           |   routing messages may not   |
 > |                        |           |     reach their intended     |
 > |                        |           |         destinations.        |

What is the reason to make this less than 255 in the default case?

 > |           MTU          |   TBD --  |    Determines the maximum    |
 > |                        |  depends  |  number of RFC 5444 AddrBlk  |
 > |                        |     on    |            entries           |
 > |                        |  address  |                              |
 > |                        |   family  |                              |
 > +------------------------+-----------+------------------------------+

This description is either unnecessary (if you mean MTU as in "interface 
maximum transfer unit") or confusing.

 > Table 4: Default Parameter Values
 >
 > In addition to the above parameters and timing values, several
 > administrative options exist.  These options have no influence on
 > correct routing behavior, although they may potentially reduce AODVv2
 > protocol messaging in certain situations.  The default behavior is to
 > NOT enable any of these options; and although many of these options
 > can be administratively controlled, they may be better served by
 > intelligent control.  The following table enumerates several of the
 > options.
 >
 > +-------------------------+-----------------------------------------+
 > |           Name          |               Description               |
 > +-------------------------+-----------------------------------------+
 > |    APPEND_INFORMATION   |     Whether or not appending routing    |
 > |                         |  information for AddedNodes to a RteMsg |
 > |                         |               is enabled.               |

This is a "strange" default value.

Page 41:

 > |  CONTROL_TRAFFIC_LIMIT  |            TBD [50 msgs/sec?]           |
 > +-------------------------+-----------------------------------------+

Packets per second?

Page 42:

 > |  Packet source IP | 12 - |  4 or  | Provides the IP address for   |
 > |      address      |  TBD |   16   | RERR messages generated due   |
 > |    (PktSource)    |      | octets | to inability to deliver a     |
 > |                   |      |        | packet.                       |

I remember that there were some concerns putting addresses into TLVs 
when we talked about DLEP in April.

 > |    Metric Type    | 13 - |    1   | Type of metric in the Metric8 |
 > |                   |  TBD |  octet | or Metric16 AddrTLV.          |
 > +-------------------+------+--------+-------------------------------+

As I said before, I would remove this TLV completely.

 > Table 7: Message TLV Types
 >
 > 15.3.  Address Block TLV Specification

The types collide with your allocation in chapter 15.2, which was called 
"Message and Address Block TLV Type Specification".

 > +---------------+------------+----------+---------------------------+
 > |      Name     |    Type    |  Length  | Value                     |
 > +---------------+------------+----------+---------------------------+
 > | VALIDITY_TIME | 1[RFC5497] |  1 octet | The maximum amount of     |
 > |               |            |          | time that information can |
 > |               |            |          | be maintained before      |
 > |               |            |          | being deleted.  The       |
 > |               |            |          | VALIDITY_TIME TLV is      |
 > |               |            |          | defined in [RFC5497].     |
 > |               |            |          | --                        |
 > |    Sequence   |  10 - TBD  | 2 octets | The latest AODVv2         |
 > |     Number    |            |          | sequence number           |
 > |    (SeqNum)   |            |          | associated with the       |
 > |               |            |          | address.                  |
 > |    Metric8    |  11 - TBD  |  1 octet | 8-bit Cost of the route   |
 > |               |            |          | to reach the destination  |
 > |               |            |          | address.                  |
 > |    Metric16   |  12 - TBD  | 2 octets | 16-bit Cost of the route  |
 > |               |            |          | to reach the destination  |
 > |               |            |          | address.                  |
 > +---------------+------------+----------+---------------------------+

Why not just one Metric TLV which can have a length of 1-2 ? You have an 
explicit length field in the message anyways.

 > Table 8: Address Block TLV (AddrTLV) Types
 >
 > The same number space should be used for both Metric8 and Metric16
 > metric types.
 >
 > 15.4.  Metric Type Number Allocation

"Metric TLV Extension Types Allocation" ?

 > Metric types are identified according to the assignments as specified
 > in [RFC6551].  The metric type of the Hop Count metric is assigned to
 > be 3, in order to maintain compatibility with that existing table of
 > values from RFC 6551.  If non-additive metrics are to be used, the
 > specification for assessing the usability of route updates (see
 > Section 6.1 ) may require changes.

"non-addititve metrics are not supported in this draft" ?

Page 43:

 > +-----------------------+----------+-----------+
 > |          Name         |   Type   |    Size   |
 > +-----------------------+----------+-----------+
 > |        Reserved       |     0    | Undefined |

Why is 0 reserved? 0 would be the Extension type that can skip the 
additional byte in the TLV.

 > |      Unallocated      |  1 -- 2  |    TBD    |
 > |       Hop Count       |  3 - TBD |  1 octet  |
 > |      Unallocated      | 4 -- 254 |    TBD    |
 > |        Reserved       |    255   | Undefined |
 > +-----------------------+----------+-----------+
 >
 > Table 9: Metric Types

Page 47:

 > Appendix A.  Example RFC 5444-compliant packet formats
 >
 > The following three subsections show example RFC 5444-compliant
 > packets for AODVv2 message types RREQ, RREP, and RERR.  These
 > proposed message formats are designed based on expected savings from
 > IPv6 addressable MANET nodes, and a layout for the Address TLVs that
 > may be viewed as natural, even if perhaps not the absolute most
 > compact possible encoding.
 >
 > For RteMsgs, the msg-hdr fields are followed by at least one and
 > optionally two Address Blocks.  The first AddrBlk contains OrigNode
 > and TargNode.  For each AddrBlk, there must be AddrTLVs of type
 > Seqnum and of type Metric.

You should be able to parse any number of address blocks.

Page 48:

 > A.1.  RREQ Message Format
 >
 > The figure below illustrates a packet format for an example RREQ
 > message.
 >
 > 0                   1                   2                   3
 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > | PV=0 |  PF=0  | msg-type=RREQ | MF=4  | MAL=3 |  msg-size=24  |
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

msg-size = 28 ?

 > |  msg-size=24  | msg-hop-limit |      msg.tlvs-length=0        |
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > |   num-addr=2  |1|0|0|0|0| Rsv | head-length=3 |Head(Orig&Targ)|
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > | Head (bytes for Orig & Target)|   Orig.Tail   |  Target.Tail  |
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > |      addr.tlvs-length=11      |  type=SeqNum  |0|1|0|1|0|0|Rsv|
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > | Index-start=0 | tlv-length=2  |     Orig.Node Sequence #      |
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > |  type=SeqNum  |0|1|0|1|0|0|Rsv| Index-start=0 | tlv-length=1  |
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

type = Metric-TLV ?

 > | OrigNodeHopCt |
 > +-+-+-+-+-+-+-+-+

 > RREQ with SeqNum and Metric AddrTLVs added, and: - two addresses in
 > Address Block - address length = 4 [IPv4], shared initial bytes = 3 -
 > Sequence Number available only for Orig.Node in addr.tlv - Hop Count
 > available only for Orig.Node in Metric8 AddrTLV - Addresses stored in
 > the order OrigNode, TargNode

Page 49:

 > 0                   1                   2                   3
 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > | PV=0 |  PF=0  | msg-type=RERR | MF=4  | MAL=3 |  msg-size=25  |
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > |  msg-size=25  | msg-hop-limit |      msg.tlvs-length=0        |
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > |   num-addr=2  |1|0|0|0|0| Rsv | head-length=3 |Head(Two Dests)|
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > | Head (for both destinations)  |  Tail(Dest_1) | Tail(Dest_2)  |
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > |      addr.tlvs-length=8       |  type=SeqNum  |0|1|0|1|0|0|Rsv|
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If these sequence numbers are one for each destination, the TLV is wrong.

It doesn't need the Index-start (because it will explicitly refer to all 
addresses in the block), but it needs the tismultivalue flag. In 
addition to this the length of the TLV must be 4.

 > | Index-start=0 | tlv-length=2  |        Dest_1 Sequence #      |
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > |        Dest_2 Sequence #      |
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >
 > RERR with - Two Unreachable Node address in Address Block - address
 > length = 4 [IPv4], shared initial bytes = 3 - Two Sequence Numbers
 > available in addr.tlv - Addresses stored from Originator to Target

Page 50:

 > A.4.  RREP_ACK Message Format
 >
 > The figure below illustrates a packet format for an example RREP_ACK
 > message.
 >
 >
 > 0                   1                   2                   3
 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > | PV=0 |  PF=0  |msg-type=RREPAk| MF=0  | MAL=3 |  msg-size=3   |
 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 > |  msg-size=3   |
 > +-+-+-+-+-+-+-+-+

msg-size = 4 ?

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 3 Dec 2012 13:31:15 +0000

> Do you really need this abbreviation?

That's directly from 5444, where it is used in a picture as it's a 4 bit field that needed a 7 absolute maximum. 5 preferred maximum, character abbreviation.

(I haven't yet looked at the draft myself, and am not sure when exactly I'll get the time.)

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 3 Dec 2012 13:38:08 +0000

> minimal Packet-Header in front of the first message (which is a single 0 

Henning is right that you can't drop the packet header. But I don't exactly agree with the way to present this fact.

If using 5444, in particular on the manet UDP port/IP protocol, the packet header is outside the remit of AODVv2. You can say that AODVv2 provides instructions that it should include something, and you can say that if something is present then AODVv2 can use it. But that's about it. It's actually misleading to include any further packet information in the draft. I think NHDP and OLSRv2 provide models of this, though I haven't checked their wording before sending this.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 03 Dec 2012 06:51:38 -0800

Hello Henning,

Your review is much appreciated.
Just a few follow-up comments for now, more later:

> I still do not like this special value.

Whether the special value is needed depends on how the SeqNum TLV
is defined.  Since Address TLVs are constrained to have the same
"cardinality" as the Address Block they refer to, but the SeqNum is
often unknown for one of the addresses in the Block, there seems
to be a need for a SeqNum value that isn't a legal SeqNum value.

> text and does not shorten it that much.

The debate on the proper mix of abbreviations versus fully
expanded terminology is difficult to resolve to everyone's
satisfaction.  The new AODVv2 specification uses "more
descriptive" abbreviations and is, I hope, a lot easier to
understand.  Expanding *all* abbreviations can have the
effect of making the descriptions seem overly verbose.

I'll be happy to do whatever makes the most people happy.
I am O.K. with expanding this abbreviation and others in
the document, as long as people agree it makes the document
easier to understand.

As a sort of "counter-example", usually in physics we see
formulas such as "F = ma^2" instead of "Force equals the
product of the mass and the square of the acceleration".
This seems obvious to you and me, but for some people
it's not at all obvious (e.g., what is F and what does it have
to do with ma {my mother!}?).  Abbreviations have the
following advantages:
- The abbreviated term is suddenly outside the domain of
   verbose natural language and is instead distinguished as
   an important term (e.g., protocol element)
- Abbreviations, used properly, enable more compact
   representations of formulaic information (e.g., as in the
   assignment statements).

A new abbreviation is a universal source of discomfort.
Perhaps after a little more time, you might feel comfortable
with some of the abbreviations that are used with AODVv2.
I've been reading the document with them for several weeks
now and they feel quite natural to me.  I'm pretty sure you
wouldn't want to expand all uses of, say, MPR in OLSRv2.

Anyway, there are at least two sides of this issue and I'd
hope some people might find the abbreviations to be an
improvement.

> If this is the same, why do you need "AODVv2 Sequence Number" ? Just 
> use "Sequence Number"

Check.  However, I thought that the way Sequence Numbers
were used here could be properly understood by relating their
use model to that of AODV.

> is a bad idea. Use TLVs attached to the addresses to identify their 

But this is the same way that Prefix Lengths are used to associate
additional information to the addresses in and Address Block..

> Is this an address TLV block (a list of TLVs) or an address block TLV 
> (a single TLV) ?

It was meant to denote a single address block TLV.  In all cases that are
specified in AODVv2, there is one TLV value per address in the Address
Block.

> Again, using the order of addresses as protocol semantics is a bad 
> idea. Use TLVs attached to the addresses to identify their purpose.

This would necessitate a N single address blocks for N addresses,
along with N Address Block TLVs.  That sounds like a bad idea to
me.  And, really, I have no idea why it is bad.

> Another confusing abbreviation.

See above...  Would you prefer Route.PrefixLength?

> only if non-zero? How does AODVv2 represents a "full internet" route 

AODVv2 does not represent that route, and it's explicitly defined
to be an inadmissible value for AODVv2.  However, this can be changed
so that, say, 255 is the admissible value.

> Is MAX_SEQNUM_LIFETIME different to a "Validity Time" ?

After Validity Time, a route is invalid, but the sequence number
information is still valid.  After MAX_SEQNUM_LIFETIME, the
sequence number information is no longer valid and must be
expunged.

> You mean packets, not messages?

Check.

> I think (if we keep this at all) this should move to "security 

I am O.K. with that.

> I do not agree with this MUST.

Can you say more about why you disagree?

> "have one associated TLV block" (one per address block).

It is permissible to have more than one TLV block per address
block, right?

> minimal Packet-Header in front of the first message (which is a single 
> 0 octet).

Oops, that's what I meant to say :-)

> can generate a new packet signature.

That's also approximately what I intended to say.

> > Cost(R2) <= (Cost(R1) + 1).  The specification of Cost(R) and

For Hop Count, it turns out that you can add one and still have
loop freedom.

> Could the Cost() function be used locally to calculate the original 
> link cost, so that it doesn't need to be considered anymore when 
> receiving and processing messages ?

Well, that's about what would happen in reality.

> This is not part of the Message.

O.K.  I am happy to leave that out, or else I can say
"Packets containing a RteMsg", whichever people think
is more clear.

> Not clear to which addresses these TLVs belong.

They belong to the preceding address block, as it's described
in RFC 5444 (to my understanding).

> A second address block? Couldn't these be inside the first address 
> block too?

Yes, I could define an address block with special meaning for the
first two addresses that are different than the rest of the addresses.
I thought that would be considerably more complicated to
understand, especially as including the rest of the addresses is
an optional feature from a long time ago.

> I am not sure if the diagram above is really helpful understanding 
> what a message looks like.

I hope it seems more helpful after a few more days consideration.
Or if you have suggestion on how to make it better I will be happy
to try something new.

> There is no constraint in RFC5444 to add this field to a message. 
> Unless you plan to use it.

The constraint is that it has to be set to zero, if it's included.
I understand why the constraint was made, but I don't
agree that the constraint is needed.  However, I am not
right now trying to propose changes to RFC 5444.

> maybe just call it (Internet) Gateway instead of IAR?

O.K.  Ian had abbreviated it, but I am O.K. with your suggestion.

> Its not allowed to have two gateways to the Internet for an AODVv2 MANET?

I will think about that.

> What is the reason to make this less than 255 in the default case?

Because the AODVv2 messages aren't going to be
traversing hundreds of hops in any imaginable future
AODVv2 network.

> This description is either unnecessary (if you mean MTU as in 
> "interface maximum transfer unit") or confusing.

I am O.K. to leave this out.  Maybe it can go in the Terminology
section and cite a relevant RFC.

> This is a "strange" default value.

You're right :-)

> Packets per second?

O.K.

> when we talked about DLEP in April.

Well, the information has to go somewhere.  I could define a new
"type" of Address Block, or Address Block with one Address and
new TLV type.  These are all more and more verbose (bloated?)
ways of going about imparting the same information.  I admit that
I get tired of seeing message size grow and grow for reasons that
don't really make very much sense to me.

Should I look up the DLEP discussion from April, or do you happen
to remember what the objection was?

> "non-addititve metrics are not supported in this draft" ?

O.K...

> You should be able to parse any number of address blocks.

Do you mean to suggest that a protocol cannot define messages
that have specific meanings for the address blocks it uses?

-- 
Regards,
Charlie P.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 3 Dec 2012 15:19:06 +0000

> along with N Address Block TLVs.

Without at this point taking a view as to whether conveying information
by order is a good idea or not, I'm just going to address the latter point.
There's absolutely no reason why conveying the function of addresses 
using TLVs requires separate address blocks. An illustration of a case
where one address block contains multiple addresses with different
functions is in the example HELLO message in one of the appendices
to NHDP (RFC 6130).

> It is permissible to have more than one TLV block per address

No. See grammar in 5444. Each address block is followed by exactly
one TLV block. That can have multiple TLVs in it of course, which does
everything you want.

> that have specific meanings for the address blocks it uses?

There is, as a matter of fact, no specification in 5444 on the subject.
5444 is consistent with allowing this.

Now there are people, Henning is clearly one and I know others,
who strongly feel that although not prohibited by the wording of
5444, this is contrary to the spirit of 5444. This viewpoint as I have
seen it expressed (not by Henning, who may or may not agree
with this bit) is that the intent is to be able to associate attributes
with addresses, attributes being expressed using TLVs. People
may have created generic 5444 parsers which assume this model.

What is the case is that NHDP and OLSRv2 take this approach.
NHDP in particular carries both local and neighbour addresses.
It could have been part of the design to put one before the other,
in separate or the same address blocks. But that approach was not
followed.

There's also, while discussing this, a separate but related issue
that neither NHDP nor OLSRv2 attach any meaning to the absence
of a TLV. It could have been the design of NHDP that any address
without some sort of neighbour TLV was a local address. This was
explicitly not done, in order to allow possible additions of other
addresses in extensions, with their own TLVs.

Unfortunately, the authors of 5444 lacked the time to write a
rationale (perhaps an informational draft) for design decisions
made in 5444, which might have considered some of these topics
(with or without conclusions). (The authors have some unpublished
material, but not a coherent draft. I does remain on a maybe list,
especially when they start issuing more than 24 hours in a day.)

So in short, it's not banned, but some people have an unpublished
view as to how things should or should not be used that go further
that the strict limits of 5444. I'm still not stating a personal view,
just that I think neither of the views "it's not prohibited" and
"it works better as an address /association mapping" should be
dismissed out of hand.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 03 Dec 2012 10:32:43 -0800

Hello Chris,

> functions is in the example HELLO message in one of the appendices

Err, right -- but isn't it correct to say "one Address Block TLV", where 
the one
Address TLV block has N TLV values, and even multiple TLVs of different TLV
types?

And isn't it O.K. that some of the TLVs have N values, one per address 
in the
address block?  Then doesn't that automatically imply that each of the 
values
in the TLV is supposed to be associated with the corresponding positionally
located address in the Address Block?

If a protocol message needs two Address Blocks for two different purposes,
why isn't is O.K. to say that the first block is for purpose_A and the 
second
address block is for purpose_B...?

What RFC 5444 calls a TLV is a lot more like what I would have expected
to be called a TLV "array" or "list" (or "block", but that term is already
consumed by RFC 5444).  My understand of TLV had (before RFC 5444)
been that "Value" is singular -- the interpretation most intuitive from the
"name" TLV and many previous RFCs and the Wikipedia definition
      http://en.wikipedia.org/wiki/Type-length-value

But never mind, I'm not proposing to change RFC 5444.  I'm only trying
to explain why using generally intuitive terminology is not so simple,
and I appreciate the help in trying to get it right for AODVv2.

> one TLV block. That can have multiple TLVs in it of course, which does

See above...  so if my understanding above is correct, I agree with you and
please excuse the use of wrong "TLV block" terminology.

> 5444 is consistent with allowing this.

Whew!

-- 
Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 4 Dec 2012 00:56:38 +0100

Any routing protocol using rfc5444 defines its protocol addresses,
messages, TLVs blocks, or values for its purposes, I think the way
explained in the draft fits AODVv2 purposes, and does not violate
rfc5444.

AB

On 12/3/12, Charles E. Perkins <[email-masked]> wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 4 Dec 2012 01:19:26 +0100

> and I appreciate the help in trying to get it right for AODVv2.

RFC5444 is a general format. We may need to update RFC5444 or
introduce new message formatting in MANET, however, it still not
necessary to limit routing functions' advantages for fitting a general
format.

AB

---

From: Henning Rogge <[email-masked]>
Date: Tue, 4 Dec 2012 09:29:33 +0100

On 12/03/2012 07:32 PM, Charles E. Perkins wrote:
> Err, right -- but isn't it correct to say "one Address Block TLV",
> where the one Address TLV block has N TLV values, and even multiple
> TLVs of different TLV types?

When I read "Address Block TLV" I think you are talking about a TLV... 
while if you say "Address TLV Block" I think you are talking about a 
block of TLVs.

Most likely its just wording, but I was confused about it.

> And isn't it O.K. that some of the TLVs have N values, one per
> address in the address block?  Then doesn't that automatically imply
> that each of the values in the TLV is supposed to be associated with
> the corresponding positionally located address in the Address Block?

Each TLV in the TLV-Block associated with an Address block can apply to 
one address (any of the addresses in the block), a sequence of 
continuous addresses or all of the addresses.

> If a protocol message needs two Address Blocks for two different
> purposes, why isn't is O.K. to say that the first block is for
> purpose_A and the second address block is for purpose_B...?

The problem I have with this approach is that we are making it harder to 
extend the message later. If you can discover the meaning of an address 
by looking at one of the attached TLVs, it is much easier to add more 
data to the message without breaking old parsers.

The advantage I see in a format like RFC5444 is that we don't need a 
"hidden semantic", everything can be contained in the TLVs and addresses 
with attached TLVs.

> What RFC 5444 calls a TLV is a lot more like what I would have
> expected to be called a TLV "array" or "list" (or "block", but that
> term is already consumed by RFC 5444).  My understand of TLV had
> (before RFC 5444) been that "Value" is singular -- the interpretation
> most intuitive from the "name" TLV and many previous RFCs and the
> Wikipedia definition http://en.wikipedia.org/wiki/Type-length-value

An address-TLV in RFC5444 can have a single value for a single address, 
multiple values for a sequence of addresses or a single value for a 
sequence of addresses.

Henning Rogge

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 05 Dec 2012 13:45:02 -0800

Hello Henning,

Here is some more follow-up on your observations and suggestions.

> text and does not shorten it that much.

Would you like to see this terminology changed to instead be "Handler"?
I guess there's no need to constantly remind the reader that the node
doing the AODVv2 processing is a "router"...

> See comment to "HandlingRtr".

Well, yes, but here the abbreviation really is a bit shorter.

> If this is the same, why do you need "AODVv2 Sequence Number" ? Just 

O.K.  I will change the instances of AODVv2 Sequence Number as you 
suggest, and use
"Sequence Number" instead.  It does read better that way.
> TargRtr? TargetRtr? TargetRouter?

I'll make them all consistent, using TargRtr.

> Maybe RREQ{field} to be costistent with the Route notation?

It turns out that the '.' notation was much more prevalent,
so I changed Route[Addr]{field} to be Route[Addr].{field}.

> Do you really need this abbreviation?

Do you mean MAL?  Or MsgHdr?

I have gone through the document and replaced MsgHdr with
Message Header.  In some cases, this required a bit of rewording
for easier reading.

> is a bad idea. Use TLVs attached to the addresses to identify their 

Still pondering this, and awaiting more discussion on the mailing list...

> The following notation suggests its a TLV block.

It is intended to be a TLV block as defined by RFC 5444, and the
description changed accordingly.

> different TLV is confusing.

Please let me know if you still think so after a few more days.
To me, this seems very natural.

However, the term is never used in the document, so I have deleted it.

> RteMsg ? Less abbreviations!

RteMsg turns out to be a very handy abbreviation.  Maybe if there
are fewer other abbreviations, RteMsg won't seem so unwelcome.
I'm trying to reduce them.

> > the Route.PfxLen is nonzero and different than the length of

I have changed instances of PfxLen to be PrefixLength.

> only if non-zero? How does AODVv2 represents a "full internet" route 

As mentioned before, I don't think  that's a useful PrefixLength,
but I have changed the invalid value to be INVALID_PREFIX_LENGTH
(255) instead of zero.

> > The time at which BlacklistNode will be removed from the

Done and Done.

> You mean packets, not messages?

Fixed.

> I do not agree with this MUST.

I am O.K. to move this to the Security Considerations, but I am
awaiting for more mailing list discussion.  I don't see the problem,
though...

> minimal Packet-Header in front of the first message (which is a single 

Fixed.

> can generate a new packet signature.

I agree.  But do you think that the wording quoted above is misleading?

> This is not part of the Message.

O.K.  I have taken these blocks out.

> instead of the MetricTypeTLV.

I don't really understand that.  The Extension Type is for 16-bit types, 
right?
I thought it would be better to have the MetricTypeTLV instead of different
AddrTLV types for each metric...?

> Not clear to which addresses these TLVs belong.

I'm hoping it should be clear that they're for the
preceding AddrBlk.  RFC 5444 grammar says:

        <message>    := <msg-type>
                          .....
                        <tlv-block>
                        (<addr-block><tlv-block>)*

so that the <tlv-block> should be associated with
the preceding <addr-block> in all cases... (?)

> A second address block? Couldn't these be inside the first address 

No, because different AddrTLV blocks might apply.

> what a message looks like.

The parts of the message are laid out in the order they appear
in the message... can you suggest how can it be made more clear?

> RFC 5444 description? I do not think you need to worry about this 
> here, its the choice of the implementation if it want to use 

There may be instances of AddrBlks of addresses for which only some
of the addresses have associated prefix lengths.  I guess I "could" leave
out this information, but I didn't think it would hurt to leave it in.

> Not part of the message.

Deleted.

> Message-TLVs are not part of the RFC5444 message header.

Hmm...  I tried to reword it to fix this problem.

> maybe just call it (Internet) Gateway instead of IAR?

I am O.K. with this, but there might be some additional context associated
with the name "Gateway".  I'll delay following this suggestion until there
is a little more discussion on the mailing list.

> Its not allowed to have two gateways to the Internet for an AODVv2 MANET?

This is related to multi-homing.  There are some considerations about
multi-homing in Section 4 that apply.  I'd rather not enlarge the 
specification
to do multi-homing any time soon, although there is one relatively
straightforward way to do it.

> "interface maximum transfer unit") or confusing.

I have deleted this table entry.  The abbreviation only appears
once elsewhere in the document.  I reckon everyone will know
what it means.

> Packets per second?

Fixed.

> The types collide with your allocation in chapter 15.2, which was 
> called "Message and Address Block TLV Type Specification".
>
> Why not just one Metric TLV which can have a length of 1-2 ? You have 
> an explicit length field in the message anyways.
>

Fixed.

> additional byte in the TLV.

O.K.  I have changed it to be Unallocated.

> You should be able to parse any number of address blocks.

This is related to your earlier comment, and I'm hoping to get some
more discussion about this on the mailing list.

> msg-size = 28 ?

Fixed.

> type = Metric-TLV ?

type=Metric

> It doesn't need the Index-start (because it will explicitly refer to 
> all addresses in the block), but it needs the tismultivalue flag. In 

Fixed.

And, again, thanks very much for your comments.

I probably need to update the Examples again, and to take time to
proofread the RFC 5444 flags fields carefully.

-- 
Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 6 Dec 2012 09:37:59 +0100

> doing the AODVv2 processing is a "router"...

I think we should have a discussion on the list if that many 
abbreviations are really useful/necessary for a draft/rfc. In my opinion 
they have no advantage (beyond saving a few characters) and make the 
draft harder to read.

> Still pondering this, and awaiting more discussion on the mailing list...

I agree, that would be a good idea.

> but I have changed the invalid value to be INVALID_PREFIX_LENGTH

If you don't consider this a useful prefix length, what does the "AODVv2 
mesh uplink" (the connection the the backbone internet) announce as a 
prefix?

> awaiting for more mailing list discussion.  I don't see the problem,

I am okay with having more discussion about this point.

I see a problem when combining AODVv2 with other RFC5444 using protocols 
(like NHDP). Protocols defining a RFC5444 message should be careful to 
have mandatory changes on the RFC5444 packet level.

> I agree.  But do you think that the wording quoted above is misleading?

I am not sure we need this paragraph at all.

RFC5444 packets are never forwarded at all, they are assembled only for 
a single hop by combining messages.

"deleting individual messages" doesn't make sense in this context.

> AddrTLV types for each metric...?

RFC5444 TLVs normally have a 8-Bit type field (which in the case of the 
MetricTLV is fixed), but can have an additional 8-Bit extension-type.

I suggest using this 8-Bit extension-type for storing the metric-type, 
similar to the way OLSRv2 use its metric TLV.

This will make the MetricTypeTLV unnecessary (and even save a few bytes 
in the message).

> No, because different AddrTLV blocks might apply.

As I stated before, I think giving the order and association with 
different address-blocks a semantic meaning

> in the message... can you suggest how can it be made more clear?

I think we should first discuss the "position/address-block association 
as semantics" thing on the list.

> out this information, but I didn't think it would hurt to leave it in.

This is not possible in RFC5444.

You have to state if addresses have or have not a prefix length in the 
address block header.

Its not really a problem, because you can set a 32/128 prefix length.

> is a little more discussion on the mailing list.

Okay.

> straightforward way to do it.

Okay, I wasn't sure if multiple gateways are supported or not.

> proofread the RFC 5444 flags fields carefully.

Packet/Message examples are always a pain to get right, I think everyone 
on this list will agree to this.

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 6 Dec 2012 19:24:53 +0000

One item inline… 

On Dec 6, 2012, at 3:37 AM, Henning Rogge wrote:

> I think we should have a discussion on the list if that many abbreviations are really useful/necessary for a draft/rfc. In my opinion they have no advantage (beyond saving a few characters) and make the draft harder to read.
> 
> If you don't consider this a useful prefix length, what does the "AODVv2 mesh uplink" (the connection the the backbone internet) announce as a prefix?

Not useful? It's a default route… I've used it myself *many* times.

Stan

> I see a problem when combining AODVv2 with other RFC5444 using protocols (like NHDP). Protocols defining a RFC5444 message should be careful to have mandatory changes on the RFC5444 packet level.
> 
> RFC5444 packets are never forwarded at all, they are assembled only for a single hop by combining messages.
> 
> RFC5444 TLVs normally have a 8-Bit type field (which in the case of the MetricTLV is fixed), but can have an additional 8-Bit extension-type.
> 
> I suggest using this 8-Bit extension-type for storing the metric-type, similar to the way OLSRv2 use its metric TLV.
> 
> This will make the MetricTypeTLV unnecessary (and even save a few bytes in the message).
> 
> As I stated before, I think giving the order and association with different address-blocks a semantic meaning
> 
> I think we should first discuss the "position/address-block association as semantics" thing on the list.
> 
> You have to state if addresses have or have not a prefix length in the address block header.
> 
> Packet/Message examples are always a pain to get right, I think everyone on this list will agree to this.
> 
> Henning Rogge
> 
> --

---

From: Henning Rogge <[email-masked]>
Date: Thu, 6 Dec 2012 20:40:48 +0100

> Not useful? It's a default route… I've used it myself *many* times.

Exactly my thought.

The "0.0.0.0/0" route (the default route) is the MOST common/useful
route you will see in a mesh network beyond the host routes. Its the
"the rest of the world is beyond this node" thing...

Even Sensor networks will have at least one node with this route.

Henning

-- 
Steven Hawkings about cosmic inflation: "An increase of billions of
billions of percent in a tiny fraction of a second. Of course, that
was before the present government."

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 06 Dec 2012 14:30:15 -0800

Hello Stan and Henning,

> Not useful? It's a default route… I've used it myself *many* times.

I reckon everyone on this list has used default routes for most of our
network connectivity.  But the routers in the AODVv2 specification don't
advertise default routes.

And even more to the point, they don't advertise routes like
191.2.3/0 ...

If we were going to specify more details about an Internet Gateway,
then there would be a good reason to discuss advertising default
routes, and actually I did do this for an earlier Gateway specification.

Sorry to raise your alarms...

-- 
Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 06 Dec 2012 16:39:45 -0800

Hello again Henning,

Following up on your observation about things in Section 13...

The whole section needs to be reorganized.  I think the tables
ought to be as follows:
a) Timers
     = e.g., MAX_IDLETIME
b) Protocol constants
     = e.g., INVALID_PREFIX_LENGTH
c) Administrative (functional) controls
     = e.g., USE_MULTICAST_RREP
d) Other administrative parameters and lists
     = e.g., CONTROL_TRAFFIC_LIMIT

The numbers in a) and d) would be more likely to require
consideration and adjustment when the nodes are "configured"
for service in the ad hoc network.  Numbers in b) and c) would
more likely just maintain their default values.

For each value in the four tables, the section defining its
meaning should be cross referenced.  For many values, a default
value would be provided.

Does this seem like a reasonable proposal?

I would also minimize the parameter description in the
table, preferring to keep such description in the relevant
sections in the main body of the document.

Regards,
Charlie P.

... skipping lines ...

> ... skipping lines ...

-- 
Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Fri, 7 Dec 2012 13:35:29 +0100

> sections in the main body of the document.

Maybe you could split the section into 4 subsections (13.1 to 13.4), 
each with a small introduction sentence to explain whats the purpose of 
these group of parameters.

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 7 Dec 2012 15:27:22 +0000

Charlie, 

On Dec 6, 2012, at 5:30 PM, Charles E. Perkins wrote:

> Sorry to raise your alarms…

No worries. Well, maybe some worries… ;-) 

I contend that, without any methodology ("gateway" or otherwise) to get "off of" (and conversely, "into") the MANET, the usefulness of the protocol is questionable. Otherwise, it's an exercise in creating an incredible protocol for which the prime use case is "5 guys down at the coffee house getting together to play black-ops on their computers". Forgive me, but that isn't worth it. 

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Fri, 7 Dec 2012 16:34:38 +0100

>> And even more to the point, they don't advertise routes like

Just as a comment, setting bits of the "host part" of a network route
is not really useful. the only useful "/0" route is 0.0.0.0/0 (and
::/0 if you count IPv6).

> I contend that, without any methodology ("gateway" or otherwise) to get "off of" (and conversely, "into") the MANET, the usefulness of the protocol is questionable. Otherwise, it's an exercise in c…

Yes, thats my opinion too.

@Charly:

I know, announcing prefixes (including the 0/0 prefix) is difficult
for reactive protocols, because it makes detecting a "missing route to
network node" more difficult (but not impossible).

But I think this MUST to be there in the protocol.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Fri, 7 Dec 2012 19:23:16 +0100

I'm not a fan of a routing protocol that does not support multiple
borders. Still, I am interested in reactive protocols.

Simple Internet attachment works as described in the draft. Border
replies for all destinations outside the network. Network has only
single prefix.

There are other solutions. BRDP is just one of them. Then, all
packets are sent to the border that owns the source address
prefix, if destination is outside. BRDP is proactive. I can think 
of reactive border discovery, but as paths to a border would be 
used quite frequently, I think proactive makes sense.

There are a few implementation details, such as source address
selection when there is no default gateway.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 7 Dec 2012 18:52:38 +0000

Teco, 

> replies for all destinations outside the network. Network has only

So, are you saying that a reactive protocol that has no defined method of ingress or egress to/from the MANET is a worthwhile pursuit? If so, I disagree. I think that ingress/egress MUST be well-understood; it SHOULD be a part of the document.

Regards,
Stan

[snip]

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 7 Dec 2012 20:06:27 +0100

I agree that this draft should not worry about gateways just reactive
routing. We got a proactive document submitted, and now we need
complete the reactive one in similar ways, let gateways go into other
newer drafts. If we add gateway discussions the draft will become
older :-)

AB

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 07 Dec 2012 11:15:26 -0800

Hello Stan,

Your suggestion is one that has been debated and resolved
many times.  Here's some of what I remember about the
discussion.

On 12/7/2012 7:27 AM, Stan Ratliff (sratliff) wrote:
> I contend that, without any methodology ("gateway" or otherwise) to get "off of" (and conversely, "into") the MANET, the usefulness of the protocol is questionable.

No doubt, it is useful to have ingress and egress to MANETs from the 
Internet.

However, they are useful even as standalone networks:
- Disaster scenarios
- Military scenarios
- Sensor networks / Internet of Things
- Networks with intermittent Internet connectivity
- Wireless Village

>   Otherwise, it's an exercise in creating an incredible protocol for which the prime use case is "5 guys down at the coffee house getting together to play black-ops on their computers". Forgive me, but that isn't worth it.

Several points here:
- This issue is not specific to reactive protocols.  If it's worth it 
for proactive,
    it's worth it for reactive.
- I'm delighted to provide a solution, as requested.  It would be nearly 
the same
    for proactive and reactive, but I can frame it as restricted to 
reactive.
- It doesn't have to be the same document as AODVv2; however, I can enlarge
    the current IAR section to describe the solution.  If history is any 
guide,
    doing so might prolong the amount of time needed to finalize AODVv2.
- If the five guys were important enough, it would be worth it :-) [...  
o.k.,
    just kidding here ...]

-- 
Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 7 Dec 2012 20:20:46 +0100

I agree with input and that we do for gateways issue of both proactive
and reactive in one new draft to cover Stan's concerns,

AB

On 12/7/12, Charles E. Perkins <[email-masked]> wrote:
>> I contend that, without any methodology ("gateway" or otherwise) to get
>> "off of" (and conversely, "into") the MANET, the usefulness of the
>> protocol is questionable.
>
>>   Otherwise, it's an exercise in creating an incredible protocol for which
>> the prime use case is "5 guys down at the coffee house getting together to
>> play black-ops on their computers". Forgive me, but that isn't worth it.
>
> Several points here:

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 07 Dec 2012 11:23:16 -0800

Hello Henning,

In an earlier email, you objected to my suggestion that zero
was an invalid <prefix-length> as claimed in the AODVv2
specification.  AODVv2 routers never advertise 0.0.0.0 in
any RteMsg (RREQ or RREP).

> is not really useful. the only useful "/0" route is 0.0.0.0/0 (and

This was exactly my point.

> network node" more difficult (but not impossible). But I think this 
> MUST to be there in the protocol. Henning Rogge 

As I mentioned to Stan, I'm happy to go down that road.

But I am also happy to make it into a separate document.
Either way, I think it would be a bad idea for AODVv2 routers
to advertise 0.0.0.0/0 as a general rule.  The Gateway *might*
do so, or else it might simply advertise that it's a "gateway".
I'd prefer the latter, based on various complications that the
former approach introduces.

Not all functions that are *required* for MANETs to be useful
have to be part of the reactive protocol specification.

-- 
Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 07 Dec 2012 12:07:10 -0800

Hello Henning,

I forgot to mention something...

On 12/7/2012 7:34 AM, Henning Rogge wrote:
> MUST to be there in the protocol.

In fact, AODVv2 does enable AODVv2 routers to announce prefixes
for their "client networks".  When an AODVv2 router does that,
it offers connectivity to any host on that "client network".  The
current document does not restrict the way that the AODVv2
router manages to offer this connectivity.  If router X advertises
connectivity to 191.78.79/24 (for example), then any other
AODVv2 router in the MANET that wants to send a packet to
any host on 191.78.79/24 can do so without initiating Route
Discovery, by using its network route towards router X.

This works just fine for "small" networks like 191.78.79/24.
For 0/0, it makes the Gateway into a serious bottleneck.

This feature also suggests that two different AODVv2 routers
in an RFC 5444 address block may need to advertise network
routes with different <prefix--length> values.

-- 
Regards,
Charlie P.

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 7 Dec 2012 20:29:17 +0000

On Dec 7, 2012, at 2:15 PM, Charles E. Perkins wrote:

> No doubt, it is useful to have ingress and egress to MANETs from the Internet.
> 

I've dealt with the first two use cases you describe, and ingress/egress has been an issue in every deployment. Admittedly, I'm extrapolating from my experience, but when every single customer says "I need a way to communicate with the MANET from places outside the MANET", it seems pretty compelling… And as for the "intermittent connectivity" case, yeah, I get it - it's where MANET crosses that imaginary, ill-defined line into DTN. But the fact that you *have* Internet connectivity, even intermittently, leads me to the conclusion that there needs to be a way to exploit it when it exists.

> - This issue is not specific to reactive protocols.  If it's worth it for proactive,
> - I'm delighted to provide a solution, as requested.  It would be nearly the same
>   for proactive and reactive, but I can frame it as restricted to reactive.
>   the current IAR section to describe the solution.  If history is any guide,
> - If the five guys were important enough, it would be worth it :-) [...  o.k.,
>   just kidding here …]

My feeling, FWIW, is that ingress/egress SHOULD be a part of the base document. However, I understand the concerns of people that say it might be a problem (or extend ratification time, etc etc). So, I'm interested in hearing other, interested opinions - both for DYMO/AODVv2/Whatever-we're-calling-it-this-week, as well as with regard to the LOADng spec. 

And lastly….. if the 5 guys were *that* important, they most likely wouldn't be *playing* black-ops… ;-)

Stan

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 07 Dec 2012 13:00:48 -0800

Hello Stan,

Small follow-up...

On 12/7/2012 12:29 PM, Stan Ratliff (sratliff) wrote:
> I've dealt with the first two use cases you describe, and ingress/egress has been an issue in every deployment. Admittedly, I'm extrapolating from my experience, but when every single customer says "I need a way to communicate with the MANET from places outside the MANET", it seems pretty compelling…

See my first sentence!  And, I observe that your customers didn't
restrict to reactive.  Indeed, Internet access is quite compelling,
useful, and something worthy of attention in the working group.

>   And as for the "intermittent connectivity" case, yeah, I get it - it's where MANET crosses that imaginary, ill-defined line into DTN.

DTN would be a *possible* functionality of the Gateway.
Triggering expensive but temporary link establishment might
be another.  Address autoconfiguration might be another
<please note the attempt at humor on this last point...>

Offering *egress* is, as it turns out, a different functionality
than offering *ingress*.  Not that I'm claiming they should
be in separate documents, but just pointing out something
interesting.

>   But the fact that you *have* Internet connectivity, even intermittently, leads me to the conclusion that there needs to be a way to exploit it when it exists.

Check.

> My feeling, FWIW, is that ingress/egress SHOULD be a part of the base document. However, I understand the concerns of people that say it might be a problem (or extend ratification time, etc etc).

I stand ready to go there, but just want to be clear that in
the past it's been a long row to hoe.  And, to re-emphasize,
not all features useful for MANETs have to be in the
reactive protocol document.

> So, I'm interested in hearing other, interested opinions - both for DYMO/AODVv2/Whatever-we're-calling-it-this-week,

I think that a single name change over the life of the Proposed
Standard specification isn't very much like flavor-of-the-week...??

>   as well as with regard to the LOADng spec.

I think the considerations would be practically identical.

> And lastly….. if the 5 guys were *that* important, they most likely wouldn't be *playing* black-ops… ;-)

Well, I wouldn't mess with them.

-- 
Regards,
Charlie P.

---

From: Teco Boot <[email-masked]>
Date: Sat, 8 Dec 2012 17:19:41 +0100

Op 7 dec. 2012, om 19:52 heeft Stan Ratliff (sratliff) het volgende geschreven:

> So, are you saying that a reactive protocol that has no defined method of ingress or egress to/from the MANET is a worthwhile pursuit?
I didn't say that.

> If so, I disagree. I think that ingress/egress MUST be well-understood; it SHOULD be a part of the document.
Well, it has to be specified somewhere. BGP isn't part of OSPF.

dymo-24 has the "Simple Internet Attachment", it permits only a single gateway. For many use cases, this would be fine. 

I said I'm interested in the multi-homed use cases. dymo-24 doesn't support it right now.

Teco

---

From: jpmacker <[email-masked]>
Date: Sat, 8 Dec 2012 15:48:57 -0500

I would agree these networks may be somewhat private or unique but they are often internetworked and are also often heterogeneous.  while gatewaying reactive is perhaps more difficult and there may be multiple strategies i also feel something should be in the base specification

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sat, 08 Dec 2012 13:17:18 -0800

Hello Joe,

Having a gateway from the MANET to the Internet is about the same
whether the routing protocol is proactive or reactive.  So, if this is a
necessary feature for AODVv2, then presumably it's also a necessary
feature for OLSRv2.

Since the specification would be similar in either case, should we
have one document to serve both cases?

While of course I agree that we should support Internet Gateways,
I am pretty sure it doesn't have to be part of the base specification,
for the abovementioned reason as well as several other reasons.

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: jpmacker <[email-masked]>
Date: Sun, 9 Dec 2012 00:09:45 -0500

Well the 1st part of my comment was just supporting the fact that i believe many of the networks you mentioned need border gateway solutions.  It sounded like there was disagreement on that.

2nd i said i believe "something" should be in the base specification i did not say what or whether it goes as far as a design recommendation.  Perhaps at a minimum discuss known gatewaying issues/challenges. What I dont want is the impression left that solutions are not needed because I strongly believe they are needed.

Lets discuss one document at a time.

Sent from my iPad

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 9 Dec 2012 16:33:21 +0100

I was interested in minimum change in the draft of that issue if
agreed-on/possible (and to refer to RFCs), but not to delay the draft
submission (however, I am interested but no time to work this text
like others).

I recommend that any participant that interested in such including
text/discuss regarding gateway issues in this WG draft, that
participant to write down the text (i.e what he/she want written in
the document) directly on the list (as please ADD the description ..),
this way we can discuss better and save time of opening new issues.

I don't think the editor should do all the work, or to leave issue
open while brought to the table. Do you have some thing/input to
include please reply quickly to complete this work/discussion?

AB

On 12/9/12, jpmacker <[email-masked]> wrote:
> Well the 1st part of my comment was just supporting the fact that i believe
> many of the networks you mentioned need border gateway solutions.  It
> sounded like there was disagreement on that.
>
> 2nd i said i believe "something" should be in the base specification i did
> not say what or whether it goes as far as a design recommendation.  Perhaps
> at a minimum discuss known gatewaying issues/challenges. What I dont want is
> the impression left that solutions are not needed because I strongly believe
> they are needed.
>
>>> I would agree these networks may be somewhat private or unique but they
>>> are often internetworked and are also often heterogeneous.  while
>>> gatewaying reactive is perhaps more difficult and there may be multiple
>>> strategies i also feel something should be in the base specification
>>>
>>>
>>
>> --
>> Regards,
>> Charlie P.
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 9 Dec 2012 16:37:52 +0100

IMHO, I agree to have one new draft for the issue that includes both
OLSRv2 and AODVv2, I think there was a work authored by Teco close to
the concerns that maybe used for the new draft.

AB

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 09 Dec 2012 07:55:22 -0800

Hello Joe,

O.K.  I will craft some language for that.  The reactive draft has for a 
long
time had a section discussion some minimal Gateway aspects.  I can
strengthen some of the language to respond to your concerns.

One concern in particular is that the Gateway MUST NOT inject ad hoc
routes into the Internet.

Regards,
Charlie P.

On 12/8/2012 9:09 PM, jpmacker wrote:
> Well the 1st part of my comment was just supporting the fact that i 
> believe many of the networks you mentioned need border gateway 
> solutions.  It sounded like there was disagreement on that.
>
> 2nd i said i believe "something" should be in the base specification i 
> did not say what or whether it goes as far as a design recommendation. 
>  Perhaps at a minimum discuss known gatewaying issues/challenges. What 
> I dont want is the impression left that solutions are not needed 
> because I strongly believe they are needed.
>
> On Dec 8, 2012, at 4:17 PM, "Charles E. Perkins" 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>
>> Hello Joe,
>>

-- 
Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 9 Dec 2012 17:04:22 +0100

Hi Teco,

I reading the protocol you worked on which was renew [1][2], do you
think the BRDP protocol will be recommended for this MANET gateway
issue?

[1] http://www.ietf.org/mail-archive/web/homenet/current/msg01772.html
[2] http://tools.ietf.org/id/draft-boot-brdp-framework-00.txt

AB

On 12/8/12, Teco Boot <[email-masked]> wrote:
>> So, are you saying that a reactive protocol that has no defined method of
>> ingress or egress to/from the MANET is a worthwhile pursuit?
> I didn't say that.
>
> dymo-24 has the "Simple Internet Attachment", it permits only a single
> gateway. For many use cases, this would be fine.
>

---

From: Teco Boot <[email-masked]>
Date: Sun, 9 Dec 2012 17:27:45 +0100

BRDP would fit both proactive and reactive MANETs, although it is proactive itself. It applies to Homenet also (see boot-homenet-brdp). 

Teco

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 10 Dec 2012 17:43:13 +0000

You seem to fail to have noticed that OLSRv2 already includes support for multiple gateways.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Abdussalam Baryun
Sent: 09 December 2012 15:38
To: <[email-masked]>
Cc: Stan Ratliff (sratliff)
Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

AB

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 10 Dec 2012 17:46:24 +0000

Charles E. Perkins <[email-masked]>
> routes with different <prefix--length> values.

You then need to specify prefixes for all addresses, but no problem.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 10 Dec 2012 09:48:36 -0800

Hello Chris,

I did in fact notice that OLSRv2 supports "Gateways".  As best I could
tell, they are gateways for specific subnets, not the entire Internet.

In fact AODVv2 also supports this functionality.  AODV supported it
as well.

But if OLSRv2 supports Internet Gateway attachment, and if you
could direct my attention to the specific part of the document, I'd
like to learn more.

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 10 Dec 2012 17:58:57 +0000

> necessary feature for AODVv2, then presumably it's also a necessary

And present, with the option for multiple gateways.

> have one document to serve both cases?

No, because (a) it's already in OLSRv2, and (b) there are differences.
What does a gateway with a connection to the Internet do when it
gets an RREQ for a.b.c.d, what address is in its RREP? Ditto if its entry
is a.0.0.0/8. Ditto if it has both. (OLSRv2 puts whichever of these -
which may be both - it supports and wishes to advertise in its TC
messages, that's it.)

---

From: Henning Rogge <[email-masked]>
Date: Mon, 10 Dec 2012 19:03:13 +0100

> tell, they are gateways for specific subnets, not the entire Internet.

The "entire internet" is just the prefix 0.0.0.0/0. It has been this
way since OLSRv1.

(the entire IPv6 internet could either be ::/0 or 2000::/3, depending
on if you are only interested in the global unicast or more).

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Mon, 10 Dec 2012 19:12:42 +0100

Somewhat experimental, related to this subject: we'll release an enhanced version of the SmartGateway extension in olsr.org. SmartGateway provides a stable connection to the Internet, even with dynamic topology, multiple gateways and NAT. The enhancement selects best gateway at time of connection setup and pins the selected gateway for duration of the lifetime of that connection.
A possible next-step is providing multipath to hosts. At this moment, we don't have plans to implement such further enhancements on SmartGateway. Next step is IPv6 and BRDP, and move to olsrv2. Don't hold your breath.

Teco

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 10 Dec 2012 18:13:17 +0000

You can indicate the entire Internet with 0.0.0.0/0, as previously described (I think by Henning). Nothing special.

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]] 
Sent: 10 December 2012 17:49
To: Dearlove, Christopher (UK)
Cc: <[email-masked]>
Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt

Hello Chris,

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 10 Dec 2012 18:20:46 +0000

Best gateway at time of connection is already in OLSRv2 (it's trivial in OLSRv1, just not explicitly stated).

Thinking out loud, maintaining  stable selection of gateway over the course of a connection would be a change to OLSRv2, and one that isn't backwardly compatible. If some of your routers ran OLSRv2 unmodified, and some ran something attempting a stable connection (by which I assume you mean stable selection of gateway - that information is available) by simple routing of packets then that could loop. You could tunnel to the chosen gateway, then only your endpoints and gateways would need to know what to do. What else?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Teco Boot
Sent: 10 December 2012 18:13
To: Charles E. Perkins
Cc: Dearlove, Christopher (UK); <[email-masked]>
Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt

Teco

---

From: Henning Rogge <[email-masked]>
Date: Mon, 10 Dec 2012 19:25:50 +0100

> Thinking out loud, maintaining  stable selection of gateway over the course of a connection would be a change to OLSRv2, and one that isn't backwardly compatible. If some of your routers ran OLSRv2…

Our current "Smartgateway code" for OLSRv1 is backward compatible.

We announce the presence of a "Smartgateway aware" exit node in the
0.0.0.0/0 HNA (its a bit of a hack, but it works ^^). In OLSRv2 we can
do it in a clean way by adding additional tags.

A "Smartgateway aware" Node that wants to connect to such a gateway
use an IPIP tunnel to get its information there.

Gateways and Nodes not "Smartgateway aware" work as normal.

Henning Rogge
 --

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 10 Dec 2012 18:36:54 +0000

Well, my thinking out loud got to tunnel (I didn't say IP/IP, but obviously) as the only way I could see it working.

I was about to say I couldn't see what tags you needed, but I assume what you want is a TLV which when attached to an address in a TC message (possibly only one that also has a GATEWAY TLV - that needs more thought, I think you could have a problem otherwise, and it is the clearly intended case) says "if you know about this protocol extension, please don't send packets to any of these addresses, but rather tunnel them direct to me (TC sender) with real destination header encapsulated.

That's OK at the modified OLSRv2 level. But you need that modified OLSRv2 to somehow hack IP, or intercept IP packets, or something, to do the tunnelling. It's a more active process than standard OLSRv2 that only interacts by "here's a routing table, use it" (plus messages). Yes?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 10 December 2012 18:26
To: Dearlove, Christopher (UK)
Cc: <[email-masked]>
Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt

Henning Rogge
 --

---

From: Henning Rogge <[email-masked]>
Date: Mon, 10 Dec 2012 19:55:23 +0100

> Well, my thinking out loud got to tunnel (I didn't say IP/IP, but obviously) as the only way I could see it working.

Its the easiest way to make it working without all nodes being aware
of the feature.

> I was about to say I couldn't see what tags you needed, but I assume what you want is a TLV which when attached to an address in a TC message (possibly only one that also has a GATEWAY TLV - that n…

You can also send them directly. Its more a label "I am capable of
receiving IPIP traffic... do what you want." And some information
about the kind of gateway you can expect (datarate, ect.).

> That's OK at the modified OLSRv2 level. But you need that modified OLSRv2 to somehow hack IP, or intercept IP packets, or something, to do the tunnelling. It's a more active process than standard O…

When a local nodes is SGW capable and decides to use the IPIP feature,
it sets up the tunnel and set a 0.0.0.0/0 route into the tunnel, which
is put in a special (user configurable) routing table. This way the
user can restrict this route to "non-mesh" interfaces to prevent
traffic coming from other nodes being sucked into the tunnel.

No need to hack or intercept IP at all, just a normal route setup by
the routing agent.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Mon, 10 Dec 2012 22:56:23 +0100

Next step is to set up a routing policy, based on conntrack. Having such, we can pin connections to a tunnel.

With IPv6 and dynamic, multiple addresses, source address can be used to direct packets to correct gateway. Homenet is moving towards this concept.

Teco

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 10 Dec 2012 14:21:16 -0800

Hello Teco and Chris,

I guess you'll remember that we had quite a lot of discussion about
the gateway possibilities several years ago.  Here's an old draft (that
does work) from Ryuji:
http://tools.ietf.org/id/draft-wakikawa-manet-globalv6-05.txt

If the subject matter is enlarged to include routing policy, gateway
selection, tunneling, and other matters, then I think the following

> You can indicate the entire Internet with 0.0.0.0/0, as previously described (I think by Henning). Nothing special.

Maybe the notation isn't very special, but the functionality is.

It isn't even even certain that IP-within-IP (or even tunneling
at all) is the best solution.  Of course it can be made to work.

Joe Macker's comment suggested that maybe for now it's permissible
to let that sleeping dog lie, and mention something about the
importance of Internet Gateways without immediately attempting
a full specification.

I am very much in favor of pursuing the matter, but I think it needs
to be in a separate document and maybe separate charter item.

-- 
Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 11 Dec 2012 08:07:01 +0100

On 12/10/2012 11:21 PM, Charles E. Perkins wrote:
>> You can indicate the entire Internet with 0.0.0.0/0, as previously
>>  described (I think by Henning). Nothing special.
>

I disagree on this point. While the /0 prefx is the largest prefix
possible, you can have the same trouble with overlapping prefixes and
missed smaller prefixes (including host-routes) with smaller ones.

> It isn't even even certain that IP-within-IP (or even tunneling at
> all) is the best solution.  Of course it can be made to work.

Tunneling should not be necessary to support prefixes. We only 
integrated it in the olsr.org code because our NORMAL usecase is 
multiple gateways (each using NAT) announcing a 0.0.0.0/0 prefix.

Is there a reason why you think that your strategy for the "internet 
uplink" will not work with other kinds of prefixes? I don't like the 
idea to include a hack for a special case when we already see that 
people will ask about a generic solution.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 11 Dec 2012 09:57:55 +0000

Tunnelling is a separate process from that embodied in OLSRv2, and a totally separate issue. 

But in the normal course of things, there is - for a proactive protocol - absolutely nothing special about 0.0.0.0/0 (or IPv6 equivalent).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles E. Perkins
Sent: 10 December 2012 22:21
To: Teco Boot; Dearlove, Christopher (UK)
Cc: manet
Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt

Hello Teco and Chris,

-- 
Regards,
Charlie P.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 11 Dec 2012 10:05:39 +0000

There is a generic solution - just route to nearest gateway. If you think gateway constancy is important, it appears that a modified protocol (which my interest was in understanding, and understanding compatibility of, no more at this time) is possible and consistent with OLSRv2. But in neither case is 0.0.0.0/0 special. And in neither case (especially not the OLSRv2 default, which is already specified) is whatever AODVv2 chooses to do relevant.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 11 December 2012 07:07
To: [email-masked]
Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Tue, 11 Dec 2012 11:12:13 +0100

On 12/11/2012 11:05 AM, Dearlove, Christopher (UK) wrote:
> There is a generic solution - just route to nearest gateway.

The problem with this in our usecase is the NAT on the gateways... which 
breaks all your TCP sessions when you change the gateway.

Imagine nodes sitting in between two 0.0.0.0/0 gateways. The normal 
fluctuation of the routing metric will make them hop between both 
gateways all the times.

 > If you
> think gateway constancy is important, it appears that a modified
> protocol (which my interest was in understanding, and understanding
> compatibility of, no more at this time) is possible and consistent
> with OLSRv2.

That was our idea with SmartGateway. An extension of the current 
protocol that works well with old nodes (both as nodes and gateways).

> But in neither case is 0.0.0.0/0 special.

We only do the whole tunnel/smartgw thing for 0.0.0.0/0 (and not other 
HNAs), but that just a matter of the limited implementation.

 > And in neither
> case (especially not the OLSRv2 default, which is already specified)
> is whatever AODVv2 chooses to do relevant.

Yes.

But I still think that propagating prefixes is relevant for AODVv2, not 
only the 0.0.0.0/0 prefix. Another "useful" usecase I can see is 
allowing each Node to announce a /64 prefix in an IPV6 network, which 
allows the node to deploy a local network behind the mesh node.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 11 Dec 2012 10:23:29 +0000

I can see there could be several reasons why a consistent gateway might be a good thing. Of course there are also cases where it is unnecessary (such as, even with NAT, all gateways connecting to a common later egress point where the NAT is).

And I think it is consistent with OLSRv2 in two ways - one is you can get a mix of extension aware and unaware nodes in interwork (though if the unaware nodes act as sources and you have a reason for consistency, that may be a problem). The other is that OLSRv2 doesn't actually mandate what you do with the routing information you collect. It can't - that's IP's problem. Of course it makes it clear what it expects (direct mapping to routing table) which is what I've referred to as standard OLSRv2. But what you propose as an extension doesn't contradict what OLSRv2 mandates itself.

(Incidentally if you define this, I'm wondering whether the right TLV would be GATEWAY with a new type extension. Unfortunately that can't replace the standard GATEWAY TLV, only add to it.)

When I say what a reactive protocol should do is a separate issue, that's not to suggest a reactive protocol shouldn't have gateways - in fact that seems either essential or close to that. But it's a separate design issue that involves RREQs, RREPs and all that, while for OLSRv2 it's about what's in TC messages.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 11 December 2012 10:12
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [manet] I-D Action: draft-ietf-manet-dymo-24.txt

Yes.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Tue, 11 Dec 2012 11:41:52 +0100

On 12/11/2012 11:23 AM, Dearlove, Christopher (UK) wrote:
> I can see there could be several reasons why a consistent gateway
> might be a good thing. Of course there are also cases where it is
> unnecessary (such as, even with NAT, all gateways connecting to a
> common later egress point where the NAT is).
>
> And I think it is consistent with OLSRv2 in two ways - one is you can
> get a mix of extension aware and unaware nodes in interwork (though
> if the unaware nodes act as sources and you have a reason for
> consistency, that may be a problem). The other is that OLSRv2 doesn't
> actually mandate what you do with the routing information you
> collect. It can't - that's IP's problem. Of course it makes it clear
> what it expects (direct mapping to routing table) which is what I've
> referred to as standard OLSRv2. But what you propose as an extension
> doesn't contradict what OLSRv2 mandates itself.

Yes. Thats why we only "added" a route instead of changing the behavior 
for the rest of the mesh.

Deploying a new feature that breaks old features is often too difficult.

> (Incidentally if you define this, I'm wondering whether the right TLV
> would be GATEWAY with a new type extension. Unfortunately that can't
> replace the standard GATEWAY TLV, only add to it.)

Hmm... a Gateway TLV Extension Type for defining the capability of 
"Tunnel endpoint capability? Which would allow a node to tunnel any kind 
of traffic to the node through a tunnel.

Maybe it would be a good way to use the value of the TLV to define what 
kind of tunnel you can use (IPIP, Gre, ...).

In addition to this we would like to have a way for a gateway to 
describe the capabilities of its uplink. How fast (up/down speed), if it 
NATs or not and maybe the external IPv6 prefix.

Some of this could be done by a different protocol (e.g. DHCP prefix 
delegation), others are interesting for the routing protocol itself to 
select the right gateway for a certain prefix.

Henning Rogge

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 11 Dec 2012 12:22:14 +0100

The issue (discussed at length at [HOMENE]) is source address selection in case of a multi-homed (MA)NETwork - and, as Henning says, also NAT state (if used).

Personally, I believe that this is not a MANET-specific issue, and that we should try to look to [HOMENET] to understand if their cognitions are not simply generally applicable.

Thomas

Sent from my iPad

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Tue, 11 Dec 2012 14:25:25 +0000

> Personally, I believe that this is not a MANET-specific issue, and that we should try to look to [HOMENET] to understand if their cognitions are not simply generally applicable.

Yes I completely agree.

---

From: David Young <[email-masked]>
Date: Tue, 11 Dec 2012 09:49:22 -0600

On Mon, Dec 10, 2012 at 10:56:23PM +0100, Teco Boot wrote:
> Next step is to set up a routing policy, based on conntrack. Having
> such, we can pin connections to a tunnel.

This sounds like the multiple-gateways software we developed for the
local community wireless network with the help of a graduate student and
the Google Summer of Code.  It sounds like you are pretty far along, but
just in case it is helpful, the student wrote his M.S. thesis on the
topic:

Earnhart, Michael Jeffery.  "A multiple gateway protocol for wireless
    mesh networks."  University of Illinois at Urbana-Champaign, 2007.

Dave

-- 
David Young
[email-masked]    Urbana, IL    (217) 721-9981

---

From: Henning Rogge <[email-masked]>
Date: Wed, 12 Dec 2012 07:40:45 +0100

On 12/11/2012 03:25 PM, JP Vasseur (jvasseur) wrote:
>> The issue (discussed at length at [HOMENE]) is source address
>> selection in case of a multi-homed (MA)NETwork - and, as Henning
>> says, also NAT state (if used).
>>
>> Personally, I believe that this is not a MANET-specific issue, and
>> that we should try to look to [HOMENET] to understand if their
>> cognitions are not simply generally applicable.
>>
>
> Yes I completely agree.

I had already a short talk with Teco about BRDP and how we might be able
to use it in a MANET. If I understand the current BRDP-draft correctly
we will have to add a forwarding layer for BRDP on a MANET, but that
should be not that difficult to do.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Wed, 12 Dec 2012 11:45:06 +0100

> should be not that difficult to do.

There was an interop test at Atlanta, based on OSPF extensions for Homenet. I'm not quite happy with their approach, which needs a SA&DA forwarding table for each SA prefix. Inner topology (the DA part) in all tables is equivalent, so high overhead. I suggest a singe DA forwarding table, with extension for default routes based on SA. Default routes point to BR for each SA prefix. Can be optimized for those that do not want the recursive lookup.

I also suggest border discovery that is not dependent of a routing protocol and that provides info to hosts, for address selection. I don't think attached hosts should listen and decode routing protocol messages. That is why I suggest to run BRDP on top of ND.

Teco

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 30 Dec 2012 14:45:55 -0800

Hello Henning,

I have been thinking a lot about the readability issues.

Here are notational devices used in the current specification:

      |   Route[DestAddr]   |   A route table entry towards DestAddr  |
      | Route[Addr].{field} |      A field in a route table entry     |

I am assuming these are O.K.

      |          --         | --                   |
      |   <msg-hop-count>   | RFC 5444 Message Header <msg-hop-count> |
      |   <msg-hop-limit>   | RFC 5444 Message Header <msg-hop-limit> |
      |       AddrBlk       |      an RFC 5444 Address TLV Block      |
      |      AddrBlk[1]     |    The first address slot in AddrBlk    |
      |      AddrBlk[N]     |     The Nth address slot in AddrBlk     |
      |  AddrBlk[OrigNode]  | AddrBlk[1]               |
      |  AddrBlk[TargNode]  | AddrBlk[2]               |
      |       AddrTLV       |      an RFC 5444 Address Block TLV      |
      |      AddrTLV[1]     |        the first item in AddrTLV        |
      |      AddrTLV[N]     |         the Nth item in AddrTLV         |
      |  AddrTLV[OrigNode]  | AddrTLV[1]               |
      |  AddrTLV[TargNode]  | AddrTLV[2]               |

These are pretty intuitive, given the notation already in RFC 5444.

      |      SeqNumTLV      |   Sequence Number AddrTLV for AddrBlk   |

Looks O.K. to me...?

      |       OrigNode      |             Originating Node            |
      |       RREQ_Gen      |    AODVv2 router originating an RREQ    |
      |       RREP_Gen      |   AODVv2 router responding to an RREQ   |
      |        RteMsg       |           Either RREQ or RREP           |
      |    RteMsg.{field}   |          Field in RREQ or RREP          |
      |      RteMsg_Gen     |        Router generating a RteMsg       |
      |     HandlingRtr     |             Handling Router             |
      |       TargNode      |               Target Node               |
      |   UnreachableNode   |             Unreachable Node            |

I am guessing that, if you find any of the notation difficult to read,
it would be one of these.  I have been steadily reducing the number of
different such notations over time, but the above seem to be very useful
and seem pretty transparent to me.

I have replaced "OrigRtr" by "RREQ_Gen" and "TargRtr" by "RREP_Gen" in
the version I am editing now.  This has the advantage of reducing the number
of notational devices, but did require some rewording of certain sentences
that seemed to make better sense with the earlier notation.

The case for using "RteMsg" to stand for either RREQ or RREP is pretty
strong, for anyone who believes in eliminating redundancy in specification.
There are quite many protocol actions that are the same for RREQ as they
are for RREP.  To write the relevant sections twice seems wrong to me.
However, I am quite open to using any other terminology if there are
suggestions for improvement.  For instance, one could replace all
instances of "RteMsg" by "RREQ_or_RREP", but (it seems to me) that
would typically *reduce* readability instead of enhancing it.

If the claim is that *any* such abbreviations should be replaced with
fully spelled out words, then we should have a discussion.  For instance,
"UnreachableNode" is equally readable as "Unreachable Node", but the former
has the advantage of immediately connoting a distinguished term in the
document.  I tried to have a discussion about this before, using
"F = ma" as an example (no one complained about the mistake in the
previous example, surprisingly to me).  As I said before, to someone
who knows what 'F', 'm', and 'a' mean, "F = ma" is a lot more readable
than "Force is the same as the product of mass and acceleration".
Even more to the point, "F = ma" is pretty easy to remember.
But to someone who has never before encountered the abbreviations for
those fundamental quantities, "F = ma" is impenetrable.

To reiterate after having said all that, I always remain quite open
to suggestions for ways to improve the notation.

If there are other concerns about readability, please do not hesitate
to point them out.  I have made major improvements in document
organization and editorial style during the last two months, and
so I hope that you can take a fresh look.

On 12/6/2012 12:37 AM, Henning Rogge wrote:
> abbreviations are really useful/necessary for a draft/rfc. In my 
> opinion they have no advantage (beyond saving a few characters) and 
> make the draft harder to read.
>

-- 
Regards,
Charlie P.