Extensions to OSPF to Support Mobile Ad Hoc Networking
draft-ietf-ospf-manet-or-03

[Ballot comment]
1.2  Motivation for extending OSPF to support MANETs

  The second motivation is that OSPF is a well understand and widely

s/understand/understood

  deployed routing protocol.

3.2.2  State Check Sequence TLV (SCS TLV)

  o  SCS Number: A circular two octet unsigned integer indicating the

This should say that it is in network byte order.

[Ballot discuss]
[This is a revised discuss, reflecting changes in the -02 draft].

Ran Canetti provided significant comments in a secdir review that was posted on 2 January 2009. 

The security considerations in the -02 draft is a significant improvement, and does begin
to address his general concerns.  However, it does not completely address the three
specific examples highlighted in his review.

The new text DOES clearly addresses Ran's second issue, which focused on increased
instability of wired networks arising from connection with a MANET.

The new text does not fully address the first issue (false attestations from authentic but malicious sources) and I did not see anything regarding the third issue (locating and
disconnecting undesirable endpoints).

Please consider whether this issues constitute real security threats.  If they do, please
draft some brief text (or include a pointer if they are addressed in other documents). 
If you believe these issues are not real threats, please let me know why they do not apply.

[Ballot discuss]
Sorry to point this out, but you have an Experimental I-D that is requesting the allocation of two bits in the Router-LSA Router Options field. RFC 4940 sets the allocation policy as Standards Action which (of course) demands a Standards Track RFC.

(I guess IANA might also ask you why you have left bit 14 undefined, but I guess you know some other I-D in the pipeline.)

(I'm also slightly nervous about the consequences of an Experimental RFC creating a new protocol field and registry where there was previously a zero, but I can't see how this would cause harm.)

PS. I have just been a victim of a similar issue with an OSPFv2 Experimental RFC. It sucks!

[Ballot comment]
1.2  Motivation for extending OSPF to support MANETs

  The second motivation is that OSPF is a well understand and widely

s/understand/understood

  deployed routing protocol.

3.2.2  State Check Sequence TLV (SCS TLV)

  o  SCS Number: A circular two octet unsigned integer indicating the

This should say that it is in network byte order.


3.3.6  Active Overlapping Relay TLV (AOR TLV)

  o  Reserved - Reserved for future use and MUST be ignored upon
      reception.

I think this should say that the value MUST be set to 0 by the sender.

[Ballot discuss]
I generally like the document, but I have some minor concerns described below:


Section 3.2.1 says:

  A new I bit is defined in the OSPFv3 option field.  The bit is
  defined for Hello packets and indicates that only incremental
  information is present.  See Section 3.4 for placement of the I bit
  within the OSPFv3 options field.


And section 3.4 says:

  Two new option bits are defined in the OSPFv3 Options Field
  (defined in [OSPFv3], A.2) as follows:

  o  I bit - defined in Section 3.2.1: The I bit is only defined for
      Hello packets and indicates that only incremental information is
      present.
  o  F bit - defined in Section 3.3.5: The F bit indicates that the
      node supports the Optimized Flooding mechanism as specified in
      this draft.

So Section 3.4 doesn't really define the placement of the I bit, but the section 5 does.

5.  IANA Considerations

  o  New TLV type codes are defined from LLS [LLS] TLV types values.

      TLV Name                      TLV Type
      --------                      --------
      State Check Sequence TLV          3
      Neighbor Drop TLV                4
      Request From TLV                  5
      Full State For TLV                6
      Active Overlapping Relay TLV      7
      Willingness TLV                  8

Unless I am mistaken, this conflicts with the current allocations in .

[Ballot comment]
1.2  Motivation for extending OSPF to support MANETs

  The second motivation is that OSPF is a well understand and widely

s/understand/understood

  deployed routing protocol.

3.2.2  State Check Sequence TLV (SCS TLV)

  o  SCS Number: A circular two octet unsigned integer indicating the

This should say that it is in network byte order.


3.3.6  Active Overlapping Relay TLV (AOR TLV)

  o  Reserved - Reserved for future use and MUST be ignored upon
      reception.

I think this should say that the value MUST be set to 0 by the sender.

[Ballot discuss]
I generally like the document, but I have some minor concerns described below:


Section 3.2.1 says:

  A new I bit is defined in the OSPFv3 option field.  The bit is
  defined for Hello packets and indicates that only incremental
  information is present.  See Section 3.4 for placement of the I bit
  within the OSPFv3 options field.


And section 3.4 says:

  Two new option bits are defined in the OSPFv3 Options Field
  (defined in [OSPFv3], A.2) as follows:

  o  I bit - defined in Section 3.2.1: The I bit is only defined for
      Hello packets and indicates that only incremental information is
      present.
  o  F bit - defined in Section 3.3.5: The F bit indicates that the
      node supports the Optimized Flooding mechanism as specified in
      this draft.

So Section 3.4 doesn't really define the placement of the I bit, but the section 5 does.

5.  IANA Considerations

  IANA will make assignments as explained below using the policies
  outlined in [IANA].

  o  I-bit and F-bit as defined below:

      0                  1                      2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7  8  9  0  1  2  3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+
      | | | | | | | | | | | | |F|I|*|*|*|*|DC| R| N| x| E|V6|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+

I was unable to find the registry for the Options field on IANA site. Can you please clarify what is the registry name (or URL)?

  o  New TLV type codes are defined from LLS [LLS] TLV types values.

      TLV Name                      TLV Type
      --------                      --------
      State Check Sequence TLV          3
      Neighbor Drop TLV                4
      Request From TLV                  5
      Full State For TLV                6
      Active Overlapping Relay TLV      7
      Willingness TLV                  8

Unless I am mistaken, this conflicts with the current allocations in .

[Ballot comment]
It's only necessary to cite the reference for a citation to a doc on first mention; reading, e.g., "...modifications to [OSPFv3] to support..." throughout the doc is distracting.

Acronym expansion for LSA? 

Are there some links missing or other typos in this network map?

      +---+I11        I21+---+I23  |
      |RT1|-+----------+-|RT2|------|N1
      +---+ |          | +---+      |
      |                |  VI22
      |                |  +
      |                |  |
      |                |  |
      |                |  |
      |                |  |
      |                |  +
      |                |  ^I41
      +---+ |          +---+
      |RT3|-+        +-|RT4|
      +---+I31      I42+---+

E.g., should the leftmost vertical bars be shifter right 6 or so spaces?

PROTO writeup by Acee Lindem:


  1. Have the chairs personally reviewed this version of the Internet
      Draft (ID), and in particular, do they believe this ID is ready
      to forward to the IESG for publication?

      Yes

  2. Has the document had adequate review from both key WG members and
      key non-WG members?

      Yes

      Do you have any concerns about the depth or
      breadth of the reviews that have been performed?

      No

  3. Do you have concerns that the document needs more review from a
      particular (broader) perspective (e.g., security, operational
      complexity, someone familiar with AAA, etc.)?

      No

  4. Do you have any specific concerns/issues with this document that
      you believe the ADs and/or IESG should be aware of? For example,
      perhaps you are uncomfortable with certain parts of the document,
      or have concerns whether there really is a need for it. In any event,
      if your issues have been discussed in the WG and the WG has
      indicated it that it still wishes to advance the document, detail
      those concerns in the write-up.

      No

  5. 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?

      We were unable to reach concensus on a single MANET OSPF approach
      and agreed to go forward with the three competing approaches as
      experimental RFCs.

  6. Has anyone threatened an appeal or otherwise indicated extreme
      discontent? If so, please summarise the areas of conflict
      in separate email to the Responsible Area Director.

      No

  7. Have the chairs verified that the document adheres to all
      of the ID Checklist items?

idnits 2.09.01

tmp/draft-ietf-ospf-manet-or-01.txt:

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC
4748:
   
------------------------------------------------------------------------
----

      No issues found here.

  Checking nits according to http://www.ietf.org/ietf/1id-
guidelines.txt:
   
------------------------------------------------------------------------
----

      No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
   
------------------------------------------------------------------------
----

      No issues found here.

  Miscellaneous warnings:
   
------------------------------------------------------------------------
----

      No issues found here.

  Checking references for intended status: Experimental
   
------------------------------------------------------------------------
----

      No issues found here.

      No nits found.
------------------------------------------------------------------------
--------

  8. Is the document split into normative and informative references?

      Yes

      Are there normative references to IDs, where the IDs are not
      also ready for advancement or are otherwise in an unclear state? (note
      here that the RFC editor will not publish an RFC with normative
      references to IDs, it will delay publication until all such IDs
      are also ready for publication as RFCs.)

      No - only informative references to IDs. However, the reference to OSPF
      Link-Local Signalling [LLS] probably should be normative. I will address
      with the authors. The LLS draft is in "Publication Requested" 
state.

  9. What is the intended status of the document? (e.g., Proposed Standard,
      Informational?)

      Experimental

  10. For Standards Track and BCP documents, the IESG approval announcement
      includes a write-up section with the following sections:

    * Technical Summary
    * Working Group Summary
    * Protocol Quality

    This draft includes mechanisms to reduce both flooding and hello
    overhead in a Mobile Ad Hoc Network (MANET). Simulation has shown
    that these techniques reduce the flooding overhead while
    maintaining very good reachability in the face of rapid network
    change. There have been two separate implementations - one from
    Cisco Systems and one from Boeing Phantom Works. Additionally,
    simulations were carried out by Boeing Phantomworks using the
    GTNetS simulation environment.

    While there was not agreement on this point, many felt these OSPF
    MANET mechanisms were the simplist of those proposed and
    still offered very good reductions in adjacencies and overhead.

PROTO writeup by Acee Lindem:


  1. Have the chairs personally reviewed this version of the Internet
      Draft (ID), and in particular, do they believe this ID is ready
      to forward to the IESG for publication?

      Yes

  2. Has the document had adequate review from both key WG members and
      key non-WG members?

      Yes

      Do you have any concerns about the depth or
      breadth of the reviews that have been performed?

      No

  3. Do you have concerns that the document needs more review from a
      particular (broader) perspective (e.g., security, operational
      complexity, someone familiar with AAA, etc.)?

      No

  4. Do you have any specific concerns/issues with this document that
      you believe the ADs and/or IESG should be aware of? For example,
      perhaps you are uncomfortable with certain parts of the document,
      or have concerns whether there really is a need for it. In any event,
      if your issues have been discussed in the WG and the WG has
      indicated it that it still wishes to advance the document, detail
      those concerns in the write-up.

      No

  5. 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?

      We were unable to reach concensus on a single MANET OSPF approach
      and agreed to go forward with the three competing approaches as
      experimental RFCs.

  6. Has anyone threatened an appeal or otherwise indicated extreme
      discontent? If so, please summarise the areas of conflict
      in separate email to the Responsible Area Director.

      No

  7. Have the chairs verified that the document adheres to all
      of the ID Checklist items?

idnits 2.09.01

tmp/draft-ietf-ospf-manet-or-01.txt:

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC
4748:
   
------------------------------------------------------------------------
----

      No issues found here.

  Checking nits according to http://www.ietf.org/ietf/1id-
guidelines.txt:
   
------------------------------------------------------------------------
----

      No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
   
------------------------------------------------------------------------
----

      No issues found here.

  Miscellaneous warnings:
   
------------------------------------------------------------------------
----

      No issues found here.

  Checking references for intended status: Experimental
   
------------------------------------------------------------------------
----

      No issues found here.

      No nits found.
------------------------------------------------------------------------
--------

  8. Is the document split into normative and informative references?

      Yes

      Are there normative references to IDs, where the IDs are not
      also ready for advancement or are otherwise in an unclear state? (note
      here that the RFC editor will not publish an RFC with normative
      references to IDs, it will delay publication until all such IDs
      are also ready for publication as RFCs.)

      No - only informative references to IDs. However, the reference to OSPF
      Link-Local Signalling [LLS] probably should be normative. I will address
      with the authors. The LLS draft is in "Publication Requested" 
state.

  9. What is the intended status of the document? (e.g., Proposed Standard,
      Informational?)

      Experimental

  10. For Standards Track and BCP documents, the IESG approval announcement
      includes a write-up section with the following sections:

    * Technical Summary
    * Working Group Summary
    * Protocol Quality

    This draft includes mechanisms to reduce both flooding and hello
    overhead in a Mobile Ad Hoc Network (MANET). Simulation has shown
    that these techniques reduce the flooding overhead while
    maintaining very good reachability in the face of rapid network
    change. There have been two separate implementations - one from
    Cisco Systems and one from Boeing Phantom Works. Additionally,
    simulations were carried out by Boeing Phantomworks using the
    GTNetS simulation environment.

    While there was not agreement on this point, many felt these OSPF
    MANET mechanisms were the simplist of those proposed and
    still offered very good reductions in adjacencies and overhead.

[Ballot comment]
> Note that the active overlapping relays selection algorithm is
> implementation specific, and the above is simply a suggested
> algorithm.  However, the behavior of the overlapping relays MUST
> follow that specified in the "Flooding and Relay Decisions" Section.
> Moreover, the same selection algorithm MUST be used by all nodes
> within an area.

This should be raised earlier in the document. As written, the
spec does not provide an interoperable solution. This may not be
required for an experimental specification, but at the very least
the reader should know about this after reading the introduction.

> attached to the broadcast network.  Such desginated routers must be

typo

Thomas Narten's quick review reaction was this:

When you do incremental updates, there are all sorts of failure edge cases. Its a lot like how to correctly do a sliding window protocol.
Just skimming the document, its not presented in a way that explains
the basic idea behind the details. For correctness, you need equivalent
of 3 way handshake to be sure both sides are synchronized w.r.t. shared
state.

[Ballot discuss]
Ran Canetti provided significant comments in a secdir review that
was posted on 2 January 2009.  There has been no response to this
review.  Please respond to these Last Call comments.

[Ballot comment]
> Note that the active overlapping relays selection algorithm is
> implementation specific, and the above is simply a suggested
> algorithm.  However, the behavior of the overlapping relays MUST
> follow that specified in the "Flooding and Relay Decisions" Section.
> Moreover, the same selection algorithm MUST be used by all nodes
> within an area.

This should be raised earlier in the document. As written, the
spec does not provide an interoperable solution. This may not be
required for an experimental specification, but at the very least
the reader should know about this after reading the introduction.

> attached to the broadcast network.  Such desginated routers must be

typo

[Ballot comment]
I think that it is very unfortunate that we can't agree on one single standards track approach for supporting MANET networks with OSPF. However, I understand the difficulty here, and under the circumstances  probably the least bad approach is to progress all three as experimental, and then hope to sort out differences with the aid of operational experience.

[Ballot discuss]
Ben Campbell provided significant comments in a Gen-ART Review that
  was posted on 2008-12-23.  There has been no response to this review.
  Please respond to these Last Call comments.

  The Gen-ART review can be found at:
    http://www.softarmor.com/rai/temp-gen-art/
    draft-ietf-ospf-manet-or-01-campbell.txt

IANA questions/comments:

IANA has questions about draft-ietf-ospf-manet-or-01.txt:

- in Section 3.2 you document "a new SCS TLV" but in the IANA
Considerations section it's expanded as "State Check Sequence."
This is the first reference to SCS in the document, but it isn't
expanded. You might want to add an expansion of SCS in the first
reference to the term. Or do you want the acronym (SCS) added
to the registry entry? Note that this applies to the other
TLVs as well.

Action 1:

Upon approval of this document, the IANA will make the following
assignments in the "OSPFv3 Options (24 bits)" registry at
http://www.iana.org/assignments/ospfv3-parameters

Value Description Reference
--------- ------------------------------------ ---------
TBD(0x000400) I-Bit [RFC-ospf-manet-or-01]
TBD(0x000800) F-Bit [RFC-ospf-manet-or-01]


Action 2:

Upon approval of this document, IANA will make the following
assignments in the "Open Shortest Path First (OSPF) Link Local
Signalling (LLS) - Type/Length/Value Identifiers (TLV)" registry at
http://www.iana.org/assignments/ospf-lls-tlvs

LLS Type Name Reference
----------- ------------------------------------------------ ---------
[TBD] State Check Sequence TLV [RFC-ospf-manet-or-01]
[TBD] Neighbor Drop TLV [RFC-ospf-manet-or-01]
[TBD] Request From TLV [RFC-ospf-manet-or-01]
[TBD] Full State For TLV [RFC-ospf-manet-or-01]
[TBD] Active Overlapping Relay TLV [RFC-ospf-manet-or-01]
[TBD] Willingness TLV [RFC-ospf-manet-or-01]


Action 3:

Upon approval of this document, IANA will create the following
sub-registry at
http://www.iana.org/assignments/ospfv3-parameters

Registry Name: LD Options
Registration Procedure: Standards Action
Initial contents of this sub-registry will be:

Value Description Reference
--------- ------------------------------------ ---------
0x01 U-bit [RFC-ospf-manet-or-01]


We understand the above to be the only IANA Actions for this document.