headers
The IESG | 24 May 2013 00:22
Picon
Favicon

Last Call: <draft-ietf-manet-nhdp-sec-threats-03.txt> (Security Threats for NHDP) to Informational RFC


The IESG has received a request from the Mobile Ad-hoc Networks WG
(manet) to consider the following document:
- 'Security Threats for NHDP'
  <draft-ietf-manet-nhdp-sec-threats-03.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2013-06-06. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document analyses common security threats of the Neighborhood
   Discovery Protocol (NHDP), and describes their potential impacts on
   MANET routing protocols using NHDP.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ballot/

No IPR declarations have been submitted directly on this I-D.
Permalink | Reply | 0 comments |
headers
Adrian Farrel | 23 May 2013 22:59
Picon

AD review of draft-ietf-manet-nhdp-sec-threats

Hi,

Thanks for this document which I found readable and comprehensible.

I have done my usual AD review to find issues and concerns that I think
should be resolved before the document advances to IETF last call and
IESG review. 

Since I am not a security weenie^H^H^H^H expert, my comments are sparse.
Therefore I am kicking off IETF last call at once. Please handle my
comments as part of the last call. (I have also sent a heads-up to the
Security ADs that this document definitely needs attention from the 
Security Directorate.)

Thanks for the work,
Adrian

---

I know it is not the intent of this document to propose solutions or
mitigations to any of the threats described. However, I think two things
would be useful:

1. Please add a statement of exactly this point to the Abstract and to
   the end of the Introduction.

2. Please consider adding a short section that may drive new work by
   suggesting which threats need to be addressed in new protocol work,
   which in deployment, and which by applications.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mukul Shukla | 19 May 2013 15:46
Picon

Need AODV implementations

Hi,

I want to study the security issues of AODV protocol. I need the active linux implementation of the AODV protocol. I t would be nice if I can have DSR and OLSR implementations too.

Thanks.

Mukul
_______________________________________________
manet mailing list
manet <at> ietf.org
https://www.ietf.org/mailman/listinfo/manet
Permalink | Reply | 0 comments |
headers
Joseph Macker | 19 May 2013 03:04
Picon

Publication Request for draft-ietf-manet-nhdp-sec-threats-03

Please publish draft-ietf-manet-nhdp-sec-threats-03 as an Informational RFC. The Shepherds Writeup has been uploaded and is replicated below.

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The type of document is Informational. It provides discussion and analyses useful for the internet and represents working group consensus. The document indicates "Information" (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document analyzes common security threats of the Neighborhood Discovery Protocol (NHDP), and describes their potential impacts on MANET routing protocols using NHDP. Working Group Summary: The process for reaching working group consensus on this was smooth; no controversy existed. Working group consensus behind the document is solid. Document Quality This document does not specify a protocol, therefore no implementations are available. There are several NHDP implementations existing, and the WG has a thorough understanding of the protocol and its security considerations. Personnel Joseph Macker (joseph.macker <at> nrl.navy.mil) is the document shepherd for this document. Adrian Farrel (adrian <at> olddog.co.uk) is the responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd has personally reviewed the document, and believes it is ready for forwarding to the IESG for publication. The shepherd has also run the id-nits tools. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had adequate review from both key working group members and from key non-WG members. The shepherd does not have any concerns about the depth or breadth of the reviews that have been performed. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The shepherd does not have any concerns about the document needing additional review. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. IPR disclosures were not necessary, therefore, none have been filed. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Working group consensus behind this document is solid. The document represents rough consensus of the working group as a whole, the document passed WGLC with minimal comments and consensus to move forward with publication. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) Working group consensus behind this document is solid. There have a few minor complaints that we do not believe represent consensus opinion. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. None. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. None required. (13) Have all references within this document been identified as either normative or informative? The document has split its references into normative and informative (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The shepherd has verified that document IANA consideration section exists, and is consistent with the body of the document. No actions for IANA have been requested. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None required. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None required.


_______________________________________________
manet mailing list
manet <at> ietf.org
https://www.ietf.org/mailman/listinfo/manet
Permalink | Reply | 0 comments |
headers
Emmanuel Baccelli | 7 May 2013 11:42
Picon
Picon
Favicon

Extension - MANIAC Challenge 2013 - Call for Papers/Coding

Folks,

we know that programmers are always late and therefore extend the
deadline for the MANIAC Challenge 2013 until May 17, 2013. Note that we
are not asking for a full conference submission. The focus of the
Challenge is coding and clever strategies for offloading.

Two weeks should be enough time to prepare a two page abstract sketching
preliminary ideas about your mobile offloading strategy!

The MANIAC Challenge is co-located with the 87th IETF/IRTF meeting in
Berlin. MANIAC participants get free entrance to the IETF/IRTF. Winners
of the challenge will be announced at the IRTF open meeting.

Nice chance to present cool ideas in an inspiring environment! Make your
students aware!

You like to work on mobile ad hoc networking?
You like to code?
You like to compete?
Join us and consider the following Call for Papers and Hacking!


        **  Call for Short Papers for the 3rd MANIAC Challenge  **

         Co-located with the 87th IETF meeting in Berlin, Germany
                      July 27 - August 2, 2013

                 http://2013.maniacchallenge.org

         Sponsored by: Google, ISOC, IETF, IRTF, ANR, and BMBF

The MANIAC Challenge is a competition to better understand cooperation and
interoperability in ad hoc networks. Competing teams students/researchers
come together to form a wireless ad hoc network, while simultaneously
connected to a backbone of access points. The organizers will generate
traffic coming from the backbone, destined to somewhere in the network. A
hop-by-hop bidding contest decides the path of each data packet towards its
destination.

Each team usually consists of two to three people. Teams will be judged
based on how much of the traffic they relay gets to its destination. To get
their traffic across the network, each team must rely on other teams
willingness to forward traffic for them. We have developed software and an
API over Android to allow teams to program their nodes, in particular
override forwarding decisions made by the routing protocol and participate
in the hop-by-hop bidding contest.

------------------------------------------------
Topic of 3rd MANIAC Challenge: Mobile Offloading
------------------------------------------------

The specific focus of the MANIAC Challenge 2013 is on developing and
comparatively evaluating strategies to offload infrastructure access points
via customer ad hoc forwarding using handhelds (e.g., smartphones,
tablets). The incentive for customers is discounted monthly fees, and the
incentive for operators is decreased infrastructure costs. The idea is to
demonstrate scenarios/strategies that do not degrade user experience while
offering significant mobile offloading on the infrastructure.
Details about the scenario and competition rules are available at

----------
Submission
----------

We solicit the submission of short papers (max. 2 pages IEEE double-column
format) describing strategies for mobile offloading. After being
peer-reviewed, authors of selected submissions will be invited to
participate in the MANIAC Challenge and to attend the IETF meeting. We
highly encourage authors to continue the development of the offloading
strategy during the review time.

Please, submit your short paper via email to maniac2013 <at> lists.fu-berlin.de.

-------------
Participation
-------------

Author participation will consist in attending the MANIAC Challenge in
Berlin, Germany, July 27 - 28, 2013. Authors are also invited to attend the
IETF/IRTF meeting July 28 - August 2, 2013. Participation in the MANIAC
Challenge is free of charge. Registration costs (at full-time student rate)
for the IETF/IRTF meeting are sponsored by ISOC.

Authors bring an implementation of the strategy described in the paper
submitted by the author, running on the common API and the common hardware
used for the event: the Nexus 7 tablet. The MANIAC API and software will be
released with the notification of acceptance. Hardware will be provided by
the organizers if necessary.

Each participant will then concurrently run its strategy during the
contest, taking place on July 27th at the Freie Universität Berlin. The
following day, a workshop will take place at the IETF venue, where we will
summarize and discuss the results of the contest.

The winners of the MANIAC Challenge 2013 will be announced during the IRTF
Open Meeting, which is part of the IETF/IRTF week with high visibility. The
IRTF Open Meeting usually will be attended by more than 100 experts from
industry and academia working on Internet Engineering.

Winners will take home some prizes to be determined with sponsors. Competing
teams will be provided complimentary IETF registration enabling them to attend
the 87th IETF meeting in Berlin, July 28 - August 2nd.

Details about the submission and participation are available at


------------
Mailing List
------------

If you are interested in the MANIAC Challenge 2013, please subscribe to
the mailing list maniac2013-info <at> lists.fu-berlin.de. We will inform you
about updates.

---------------
Important Dates 
---------------
 -  Deadline for short paper submission:   May 17, 2013 (extended)
 -  Notification of acceptance:            May 20, 2013 (extended)
 -  Release of API and software:           May 12, 2013
 -  MANIAC challenge dates:                July 27 - 28, 2013 
 -  IETF/IRTF meeting:                     July 28 - August 2, 2013

----------------
MANIAC Co-Chairs 
----------------

 - Emmanuel Baccelli (INRIA)
 - Oliver Hahm (INRIA)
 - Felix Juraschek (Freie Universität Berlin)
 - Thomas Schmidt (HAW Hamburg)
 - Heiko Will (Freie Universität Berlin)
 - Matthias Wählisch (Freie Universität Berlin)

-------
Contact
-------
For questions, please contact maniac2013 <at> lists.fu-berlin.de 

_______________________________________________
manet mailing list
manet <at> ietf.org
https://www.ietf.org/mailman/listinfo/manet
Permalink | Reply | 0 comments |
headers
Ulrich Herberg | 2 May 2013 16:34

Re: performance metrics directorate review of draft-ietf-manet-olsrv2-mib-06

AB,

I let Adrian reply if he thinks the changes are significant enough to
warrant a new WGLC. I think this is not the case. The sentence was
probably a copy&paste mistake and does not provide any value in the
Security Considerations section.

Best regards
Ulrich

On Wed, May 1, 2013 at 11:00 AM, Abdussalam Baryun
<abdussalambaryun <at> gmail.com> wrote:
> I didn't think it was out of place. However, I thought/hope no words deletes
> should occur after WGLC only if discussed (your delete was not discussed on
> list until my input). Do I have to review all versions updated after WGLC?
> some people may not, they may think it will be discussed to update I-Ds.
>
> AB
>
>
>
> On Tue, Apr 30, 2013 at 7:23 PM, Ulrich Herberg <ulrich <at> herberg.name> wrote:
>>
>> AB,
>>
>> this sentence was out-of-place in section 9 and not related to
>> security considerations.
>>
>> Best regards
>> Ulrich
>>
>> On Tue, Apr 30, 2013 at 10:58 AM, Abdussalam Baryun
>> <abdussalambaryun <at> gmail.com> wrote:
>> > Not sure in new version -07 why deleted some words/statement in section
>> > 9.
>> >
>> > AB
>> >
>> >
>> >
>> > On Mon, Apr 29, 2013 at 8:17 PM, Ulrich Herberg <ulrich <at> herberg.name>
>> > wrote:
>> >>
>> >> Adrian,
>> >>
>> >> yes, that was my intention...but sometimes, good intentions are not
>> >> enough
>> >> ;-)
>> >>
>> >> I have submitted a new revision with the one-word change that Benoit
>> >> requested.
>> >>
>> >> Best regards
>> >> Ulrich
>> >>
>> >> On Sun, Apr 28, 2013 at 10:31 AM, Adrian Farrel <adrian <at> olddog.co.uk>
>> >> wrote:
>> >> > Hi Ulrich,
>> >> >
>> >> > Did you intend to post a new revision to make this change?
>> >> >
>> >> > Thanks,
>> >> > Adrian
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Ulrich Herberg [mailto:ulrich <at> herberg.name]
>> >> >> Sent: 15 April 2013 21:11
>> >> >> To: Benoit Claise
>> >> >> Cc: draft-ietf-manet-olsrv2-mib <at> tools.ietf.org; Adrian Farrel;
>> >> > pm-dir <at> ietf.org;
>> >> >> manet <at> ietf.org
>> >> >> Subject: Re: [manet] performance metrics directorate review of
>> >> >> draft-ietf-
>> >> >> manet-olsrv2-mib-06
>> >> >>
>> >> >> Benoit,
>> >> >>
>> >> >> thank you very much for this review. I agree that using the term
>> >> >> "performance information" instead of "performance metrics" is a good
>> >> >> idea. We will make the change.
>> >> >>
>> >> >> Best regards
>> >> >> Ulrich
>> >> >>
>> >> >> On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise <bclaise <at> cisco.com>
>> >> >> wrote:
>> >> >> > Dear all,
>> >> >> >
>> >> >> > I reviewed
>> >> >> > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06,
>> >> >> > from a
>> >> >> > performance metric directorate point of view.
>> >> >> >
>> >> >> > This draft doesn't contain any reference to RFC6390, but contains
>> >> >> > "performance metric". Hence this review was triggered. For details
>> >> >> > about the
>> >> >> > directorate, see
>> >> >> > http://www.ietf.org/iesg/directorate/performance-metrics.html
>> >> >> >
>> >> >> >
>> >> >> > Definition of Managed Objects for the  Optimized Link State
>> >> >> > Routing
>> >> >> > Protocol version 2
>> >> >> >
>> >> >> > Abstract
>> >> >> >
>> >> >> >    This document defines the Management Information Base (MIB)
>> >> >> > module
>> >> >> >    for configuring and managing the Optimized Link State Routing
>> >> >> >    protocol version 2 (OLSRv2).  The OLSRv2-MIB module is
>> >> >> > structured
>> >> >> >    into state information, performance metrics, and notifications.
>> >> >> > This
>> >> >> >    additional state and performance information is useful to
>> >> >> >    troubleshoot problems and performance issues of the routing
>> >> >> > protocol.
>> >> >> >    Different levels of compliance allow implementers to use
>> >> >> > smaller
>> >> >> >    subsets of all defined objects, allowing for this MIB module to
>> >> >> > be
>> >> >> >    deployed on more constrained routers.
>> >> >> >
>> >> >> >
>> >> >> > Basically, all performance metrics come from this table:
>> >> >> >
>> >> >> >    o  olsrv2InterfacePerfTable - records performance counters for
>> >> >> > each
>> >> >> >       active OLSRv2 interface on this device. selected path to
>> >> >> > each
>> >> >> >       destination for which any such path is known.  This table
>> >> >> > has
>> >> >> >       AUGMENTS { nhdpInterfacePerfEntry } and as such it is
>> >> >> > indexed
>> >> >> > via
>> >> >> >       nhdpIfIndex from the NHDP-MIB.
>> >> >> >
>> >> >> > NHDP-MIB is RFC 6779:
>> >> >> >    NhdpInterfacePerfEntry ::=
>> >> >> >       SEQUENCE {
>> >> >> >          nhdpIfHelloMessageXmits
>> >> >> >             Counter32,
>> >> >> >          nhdpIfHelloMessageRecvd
>> >> >> >             Counter32,
>> >> >> >          nhdpIfHelloMessageXmitAccumulatedSize
>> >> >> >             Counter64,
>> >> >> >          nhdpIfHelloMessageRecvdAccumulatedSize
>> >> >> >             Counter64,
>> >> >> >          nhdpIfHelloMessageTriggeredXmits
>> >> >> >             Counter32,
>> >> >> >          nhdpIfHelloMessagePeriodicXmits
>> >> >> >             Counter32,
>> >> >> >          nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount
>> >> >> >             Counter32,
>> >> >> >          nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount
>> >> >> >             Counter32,
>> >> >> >          nhdpIfHelloMessageXmitAccumulatedLostNeighborCount
>> >> >> >             Counter32
>> >> >> >       }
>> >> >> >
>> >> >> >
>> >> >> > This draft contains similar objects in olsrv2InterfacePerfTable :
>> >> >> >
>> >> >> >     Olsrv2InterfacePerfEntry ::=
>> >> >> >        SEQUENCE {
>> >> >> >           olsrv2IfTcMessageXmits
>> >> >> >              Counter32,
>> >> >> >           olsrv2IfTcMessageRecvd
>> >> >> >              Counter32,
>> >> >> >           olsrv2IfTcMessageXmitAccumulatedSize
>> >> >> >              Counter64,
>> >> >> >           olsrv2IfTcMessageRecvdAccumulatedSize
>> >> >> >              Counter64,
>> >> >> >           olsrv2IfTcMessageTriggeredXmits
>> >> >> >              Counter32,
>> >> >> >           olsrv2IfTcMessagePeriodicXmits
>> >> >> >              Counter32,
>> >> >> >           olsrv2IfTcMessageForwardedXmits
>> >> >> >              Counter32,
>> >> >> >           olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount
>> >> >> >              Counter32
>> >> >> >        }
>> >> >> >
>> >> >> >
>> >> >> > Personally, I don't believe that those objects should be subject
>> >> >> > to
>> >> >> > the RFC
>> >> >> > 6390 template definition. (Performance Metric Definition Template,
>> >> >> > section
>> >> >> > 5.4.4, RFC 6390).
>> >> >> > First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was
>> >> >> > not
>> >> >> > subject to it
>> >> >> > Second reason: these objects are not really performance metrics,
>> >> >> > but
>> >> >> > mainly
>> >> >> > basic monitoring objects.
>> >> >> >
>> >> >> > Since RFC 6779 uses the term performance information (in the
>> >> >> > abstract), I
>> >> >> > would propose that draft-ietf-manet-olsrv2-mib also uses this
>> >> >> > term,
>> >> >> > and not
>> >> >> > the "performance metric". That would avoid some confusion.
>> >> >> > However,
>> >> >> keeping
>> >> >> > the olsrv2InterfacePerfTable OID name is perfectly fine, for
>> >> >> > consistency
>> >> >> > reason with RFC 6779.
>> >> >> >
>> >> >> > Regards, Benoit
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > manet mailing list
>> >> >> > manet <at> ietf.org
>> >> >> > https://www.ietf.org/mailman/listinfo/manet
>> >> >> >
>> >> >
>> >> _______________________________________________
>> >> manet mailing list
>> >> manet <at> ietf.org
>> >> https://www.ietf.org/mailman/listinfo/manet
>> >
>> >
>> >
>> > _______________________________________________
>> > manet mailing list
>> > manet <at> ietf.org
>> > https://www.ietf.org/mailman/listinfo/manet
>> >
>
>
Permalink | Reply | 3 comments |
headers
internet-drafts | 1 May 2013 18:15
Picon
Favicon

I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-04.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF.

	Title           : Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale
	Author(s)       : Christopher Dearlove
                          Thomas Heide Clausen
                          Philippe Jacquet
	Filename        : draft-ietf-manet-olsrv2-metrics-rationale-04.txt
	Pages           : 30
	Date            : 2013-05-01

Abstract:
   OLSRv2 includes the ability to assign metrics to links and to use
   those metrics to allow routing by other than minimum hop count
   routes.  This document provides a historic record of the rationale
   for, and design considerations behind, how link metrics were included
   in OLSRv2.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-metrics-rationale

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-metrics-rationale-04

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Permalink | Reply | 0 comments |
headers
Duke, Martin | 29 Apr 2013 23:36
Picon
Favicon

DLEP Draft 4 Nits

I’ve articulated some difficulties I have with the data item TLVs in this and previous drafts, but here are a couple of minor questions about the Message formats in  Draft 04:

-          In 9.16: Shouldn’t the draft describe the Status TLV termination codes somewhere?

-          Section 23: Why are Heartbeat Interval/Threshold TLVs in Heartbeat messages, particularly as mandatory TLVs?

-          Section 25: Shouldn’t there be a Status TLV in the Link Characteristics ACK Message? I can imagine routers would want to know why their requests were refused.

 

Nits about draft 04:

 

-          MAC address is missing from the TLV table at the beginning of section 9.

-          In that same list, “Transmit Latency” should be “Latency”, “Receive Resources” should be “Resources (Receive)”, and “Transmit Resources” should be “Resources (Transmit)”.

-          In 9.17: “indicates” -> “indicate”

-          Section 11: Heartbeat Interval/Threshold is a single TLV type, not two

-          So can LINK Characteristic ACK Timer TLVs be sent by routers? Section 9.18 suggests modems only, but Section 12 the opposite.  I vote “no.”

-          Section 18: “Link Factor” -> “Link Quality”

-          Section 15 states there are no optional TLVs and then lists Status as optional.

-          Section 20 refers to “Other TLVs as listed are OPTIONAL,” but there are no optional TLVs.

-          Section 22: I’m not a fan of Expected Forwarding Time but don’t know why it would be excluded from Neighbor Update Messages

-          Section 24: should probably change “Current Data Rate” to “Current Data Rate (Transmit)”

-          Section 24/25: The definitions of Current Data Rate in these two sections are switched (i.e. the ACK message should take a certain form if the request is denied).

 

Martin

_______________________________________________
manet mailing list
manet <at> ietf.org
https://www.ietf.org/mailman/listinfo/manet
Permalink | Reply | 0 comments |
headers
Adrian Farrel | 28 Apr 2013 19:31
Picon

Re: performance metrics directorate review of draft-ietf-manet-olsrv2-mib-06

Hi Ulrich,

Did you intend to post a new revision to make this change? 

Thanks,
Adrian

> -----Original Message-----
> From: Ulrich Herberg [mailto:ulrich <at> herberg.name]
> Sent: 15 April 2013 21:11
> To: Benoit Claise
> Cc: draft-ietf-manet-olsrv2-mib <at> tools.ietf.org; Adrian Farrel;
pm-dir <at> ietf.org;
> manet <at> ietf.org
> Subject: Re: [manet] performance metrics directorate review of draft-ietf-
> manet-olsrv2-mib-06
> 
> Benoit,
> 
> thank you very much for this review. I agree that using the term
> "performance information" instead of "performance metrics" is a good
> idea. We will make the change.
> 
> Best regards
> Ulrich
> 
> On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise <bclaise <at> cisco.com> wrote:
> > Dear all,
> >
> > I reviewed http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06, from a
> > performance metric directorate point of view.
> >
> > This draft doesn't contain any reference to RFC6390, but contains
> > "performance metric". Hence this review was triggered. For details about the
> > directorate, see
> > http://www.ietf.org/iesg/directorate/performance-metrics.html
> >
> >
> > Definition of Managed Objects for the  Optimized Link State Routing
> > Protocol version 2
> >
> > Abstract
> >
> >    This document defines the Management Information Base (MIB) module
> >    for configuring and managing the Optimized Link State Routing
> >    protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
> >    into state information, performance metrics, and notifications.  This
> >    additional state and performance information is useful to
> >    troubleshoot problems and performance issues of the routing protocol.
> >    Different levels of compliance allow implementers to use smaller
> >    subsets of all defined objects, allowing for this MIB module to be
> >    deployed on more constrained routers.
> >
> >
> > Basically, all performance metrics come from this table:
> >
> >    o  olsrv2InterfacePerfTable - records performance counters for each
> >       active OLSRv2 interface on this device. selected path to each
> >       destination for which any such path is known.  This table has
> >       AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed via
> >       nhdpIfIndex from the NHDP-MIB.
> >
> > NHDP-MIB is RFC 6779:
> >    NhdpInterfacePerfEntry ::=
> >       SEQUENCE {
> >          nhdpIfHelloMessageXmits
> >             Counter32,
> >          nhdpIfHelloMessageRecvd
> >             Counter32,
> >          nhdpIfHelloMessageXmitAccumulatedSize
> >             Counter64,
> >          nhdpIfHelloMessageRecvdAccumulatedSize
> >             Counter64,
> >          nhdpIfHelloMessageTriggeredXmits
> >             Counter32,
> >          nhdpIfHelloMessagePeriodicXmits
> >             Counter32,
> >          nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount
> >             Counter32,
> >          nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount
> >             Counter32,
> >          nhdpIfHelloMessageXmitAccumulatedLostNeighborCount
> >             Counter32
> >       }
> >
> >
> > This draft contains similar objects in olsrv2InterfacePerfTable :
> >
> >     Olsrv2InterfacePerfEntry ::=
> >        SEQUENCE {
> >           olsrv2IfTcMessageXmits
> >              Counter32,
> >           olsrv2IfTcMessageRecvd
> >              Counter32,
> >           olsrv2IfTcMessageXmitAccumulatedSize
> >              Counter64,
> >           olsrv2IfTcMessageRecvdAccumulatedSize
> >              Counter64,
> >           olsrv2IfTcMessageTriggeredXmits
> >              Counter32,
> >           olsrv2IfTcMessagePeriodicXmits
> >              Counter32,
> >           olsrv2IfTcMessageForwardedXmits
> >              Counter32,
> >           olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount
> >              Counter32
> >        }
> >
> >
> > Personally, I don't believe that those objects should be subject to the RFC
> > 6390 template definition. (Performance Metric Definition Template, section
> > 5.4.4, RFC 6390).
> > First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was not
> > subject to it
> > Second reason: these objects are not really performance metrics, but mainly
> > basic monitoring objects.
> >
> > Since RFC 6779 uses the term performance information (in the abstract), I
> > would propose that draft-ietf-manet-olsrv2-mib also uses this term, and not
> > the "performance metric". That would avoid some confusion. However,
> keeping
> > the olsrv2InterfacePerfTable OID name is perfectly fine, for consistency
> > reason with RFC 6779.
> >
> > Regards, Benoit
> >
> >
> >
> > _______________________________________________
> > manet mailing list
> > manet <at> ietf.org
> > https://www.ietf.org/mailman/listinfo/manet
> >
Permalink | Reply | 4 comments |
headers
Adrian Farrel | 28 Apr 2013 18:59
Picon

AD review of draft-ietf-manet-smf-mib

Hi,

Thanks for this document. Here is my AD review, the purpose of which is
to iron out issues before the document goes to IETF last call and IESG
review.

I don't have any major issues with your document, but here is a list of
minor points for consideration. All issues are up for discussion, but I
think  new revision is needed.

Thanks,
Adrian

---

In a couple of places you say "MIBs" when you should say "MIB modules"
For example:
   6.3  Relationship to the Future RSSA-MIBs

This is hardly important, but could do with being cleaned up.

---

Please don't use direct citations (in square brackets) within the body
of the MIB module. This is because the text of the MIB module will be
extracted and used as a standalone file. You already have Section 6.2
to ensure that all the references are made correctly, so all you need
to do is remove the square brackets, from within Section 7, leaving the
contents in place.
E.g.
OLD
         FROM SNMPv2-SMI                          -- [RFC2578]
NEW
         FROM SNMPv2-SMI                          -- RFC 2578
END

E.g.
OLD
          [SMF] Macker, J.(ed.),
          Simplified Multicast Forwarding, RFC XXXX,
          July 2012.
NEW
          RFC XXXX, Macker, J.(ed.),
          Simplified Multicast Forwarding, July 2012.
END

---

Copyright in the MIB module itself is out of date.

---

Please resolve the different 'XXXX' and 'xxxx' so that they are unique.
Thus,
        DESCRIPTION
           "The first version of this MIB module,
            published as RFC xxxx.
           "
        -- RFC-Editor assigns xxxx
        ::= { experimental xxxx }   -- to be assigned by IANA
...contains two different meanings of xxxx.

---

SmfOpModeID has
       SYNTAX  INTEGER {
                        independent (1),
                        routing (2),
                        crossLayer (3)
                        -- future (4-255)
               }

I take from this that:
1. the range of SmfOpModeID is 1-255
2. You do not want to assign 4-255 at this time

I think that means that you should have either
       SYNTAX  INTEGER (1..255)
and put the interpretation in comments (which isn't so helpful); or
       SYNTAX  INTEGER {
                        independent (1),
                        routing (2),
                        crossLayer (3)
               }

How worried are you that new values will be defined, and what will you
do when they are? If this is going to happen relatively soon, then you
would need to respin the whole RFC and MIB module to add the value. That
is a pain!

In that case, you would be better to move the TC to a separate MIB
module so that it can be updated without revising the OID of the main
module.

It may be that the operational mode needs to follow the setting of a
specific protocol field. In that case, you may prefer to put this TC in
an IANA MIB module so that it can be updated automatically.

See also comment on SmfRssaID.

---

There is a similar problem with enumerations and ranges in SmfRssaID.
Here you have:
       SYNTAX      INTEGER {
                           cF(1),
                           sMPR(2),
                           eCDS(3),
                           mprCDS(4)
                           -- future(5-127)
                           -- noStdAction(128-239)
                           -- experimental(240-255)
                   }

Again, I think you should either have
       SYNTAX      INTEGER (1..255)
with the information in the comment; or
       SYNTAX      INTEGER {
                           cF(1),
                           sMPR(2),
                           eCDS(3),
                           mprCDS(4),
                           exp0(240),
                           exp1(241),
                           exp2(242),
                           exp3(243),
                           exp4(244),
                           exp5(245),
                           exp6(246),
                           exp7(247),
                           exp8(248),
                           exp9(249),
                           exp10(250),
                           exp11(251),
                           exp12(252),
                           exp13(253),
                           exp14(254),
                           exp15(255)
                   }
and move the TC into a separate MIB module (possibly operated by IANA)
so that it can be easily updated.

---

   smfOpModeCapabilitiesReference OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "This object contains a reference to the document
            that defines this operational mode."
       ::= { smfOpModeCapabilitiesEntry 3 }

I think you probably need a proper reference for the format of the
string here. Is the document referenced through a URI or what?

---

You have DEFVAL clauses for a number of objects that have MAX-ACCESS
of read-write.  I don't think this makes sense.  Defaults only apply to
creatable objects meaning "this is the value to apply if this object is
created automatically without being explicitly set."

Otherwise it is entirely up to the local implementation how it sets the
object. While there may be an approved default value for a protocol
implementation, that is not a DEFVAL, but a piece of information in a
protocol specification.

---

   smfIfIndex  OBJECT-TYPE
      SYNTAX      InterfaceIndexOrZero

If you use InterfaceIndexOrZero rather than InterfaceIndex, you must
state the meaning of zero for the object.

---

Are you sure you need smfIfName in addition to ifDescr?
Are you sure you need smfIfAdminStatus in addition to ifAdminStatus?

---

A number of references of the form...

       REFERENCE
          "Simplified Multicast Forwarding for MANET
           (SMF), Macker, J., July 2012."

...should really include the RFC number (i.e. 6621) to read...

       REFERENCE
          "RFC 6621, Simplified Multicast Forwarding for MANET
           (SMF), Macker, J., July 2012."

For example at SmfOpModeID, but search for them all.

---

I think that the SMF Performance Group needs some discussion of wrapping
and discontinuities.  I think wrapping is as simple as making a 
statement that the counters wrap to zero.  I don't really understand how
to describe discontinuities - you need a MIB expert for that.
Permalink | Reply | 0 comments |
headers
Dowdell, John | 25 Apr 2013 17:36

Re: DLEP link metric discussion

Hi Teco

I believe the mesh radios would directly connect to all similar radios within range, and will mesh to other
radios through ones that are in range. The meshing protocol is likely to take care of all forwarding,
rebroadcast and multicast forwarding actions (though I'm not completely sure about multicast
forwarding). I believe (though not completely sure)some mesh radios we are testing with work out the
bandwidth to a destination by looking at each hop in turn and presenting the aggregate result to the source router.

I would agree that point to point or hub and spoke radio system would not care about bandwidth on other links,
though the management system might collect this information.

Regards

John

-----Original Message-----
From: Teco Boot [mailto:teco <at> inf-net.nl]
Sent: 25 April 2013 16:12
To: Dowdell, John
Cc: Stan Ratliff (sratliff); manet <at> ietf.org
Subject: Re: [manet] DLEP link metric discussion

Hi John,

Your example brings up some new elements: need for a congestion TLV (in scope for DLEP?) and multi topology /
traffic engineering (not in scope for DLEP, this is handled at IP routing). On congestion: would this be a
per DSCP metric?

On your definition for the mesh radio: can I assume the provided IP link is full connected and IP
broadcast/multicast capable? If so, we don't need to rebroadcast for flooding or forward over same
interface. This is important information for the routers and I support the request for a TLV for it.
Doesn't need to be in the core spec, routers can use such links to run their MANET protocol, although it is
not that efficient as it could be.

The discussion on "is provided metric for first L2 hop of a multi-hop L2 path" is a different subject. I think
this is a real world problem, as hub&spoke type of L2 topologies are widely used and spokes are typically
unaware of far end RF links. Multi-hop L2 mesh topologies are also in place. I think DLEP should be capable
to transfer any info for the L2 path to the locally connected router. Could be hopcount, total airtime, 1st
L2 hop link metrics, to name a few I am aware of.

Teco

Op 25 apr. 2013, om 14:29 heeft "Dowdell, John" <John.Dowdell <at> Cassidian.com> het volgende geschreven:

> Stan, Teco
>
> The multihop/mesh problem has a few facets, if for the purposes of this discussion we define a mesh radio
being one that is capable of doing its own layer 2 forwarding. Yes I know there is more to it than that, but I
think this is what is important here.
>
> Consider that you wish to take a journey across town on the bus. Two busses are available for you to use to
your destination, Bus A and Bus B. Bus A is the express bus, and stops at a small number of points along the
way. Bus B is the slow bus and stops at many points along the way. Unusually, this bus company is allowed to
throw you off the bus before your destination if VIPs want to get on at some intermediate stop and there are
not enough seats, and standing is not allowed.
>
> In making your choice of which bus to catch, you are not interested that either bus stops at any place before
your destination. You are however interested in how long each bus takes to get to your destination
(latency), and you are also interested in whether you will be able to get a seat on the bus for the whole of the
journey (congestion).
>
> I would suggest therefore that a router would be interested to learn that a path to a destination is via a
mesh radio, if only because it then knows that it will face competition for the bandwidth that the modem
reports is available. How the congestion is managed is not DLEP's job.
>
> BUT to re-iterate a point that Rick made earlier, the bus company needs to truthfully report the number of
seats available on each bus for you to make able to make an informed decision. Knowing that VIPs are likely
to get on is an advantage, but I'm not sure that it is strictly necessary.
>
> Bon Voyage
>
> John
>
> -----Original Message-----
> From: manet-bounces <at> ietf.org [mailto:manet-bounces <at> ietf.org] On Behalf Of Stan Ratliff (sratliff)
> Sent: 25 April 2013 04:49
> To: Teco Boot
> Cc: manet <at> ietf.org
> Subject: Re: [manet] DLEP link metric discussion
>
>
> On Apr 24, 2013, at 2:51 PM, Teco Boot wrote:
>
>>
>> Op 24 apr. 2013, om 19:18 heeft Stan Ratliff (sratliff) het volgende geschreven:
>>
>>> What if we simply state that latency and bandwidth MUST reflect the full RF path? And that, where
appropriate, latency MUST include delay introduced at any intermediate nodes?
>>
>> Why can there be any metric on parts on what is needed?
>
> There shouldn't be. But earlier in this thread, there was an example of a radio vendor that was apparently
reporting first-hop bandwidth instead of full-path bandwidth. At least that's what I gathered from the
email. I'm concerned about the notion that the router needs to (has to?) know if the physical RF is multihop
- frankly, I don't think that kind of visibility should be necessary.
>
> Regards,
> Stan
>
>
>>
>> Teco
>>
>>
>
> _______________________________________________
> manet mailing list
> manet <at> ietf.org
> https://www.ietf.org/mailman/listinfo/manet
> The information contained within this e-mail and any files attached to this e-mail is private and in
addition may include commercially sensitive information. The contents of this e-mail are for the
intended recipient only and therefore if you wish to disclose the information contained within this
e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the
intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the
sender and inform them of the error and delete the e-mail, including any attached files from your system.
Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ
Company No: 04191036 http://www.cassidian.com

The information contained within this e-mail and any files attached to this e-mail is private and in
addition may include commercially sensitive information. The contents of this e-mail are for the
intended recipient only and therefore if you wish to disclose the information contained within this
e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the
intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the
sender and inform them of the error and delete the e-mail, including any attached files from your system.
Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ
Company No: 04191036 http://www.cassidian.com
Permalink | Reply | 2 comments |

Gmane