Subject: Re: [OSPF] WG Last call for draft-ietf-ospf-manet-mpr-02.txt

From: Richard Ogier <[email-masked]>
Date: Tue, 04 Nov 2008 05:13:07 -0800

Here are my comments for draft-ietf-ospf-mpr-02.

First a general comment.
A major change from version 01 to version 02 is that there is now one
Flooding-MPR set per MANET interface (versus one set per router in
version 01), while there is still one Path-MPR set per router.
Since both Flooding-MPRs and Path-MPRs must become adjacent,
it seems to me that it would be more efficient to just have one
set of MPRs, the Path-MPRs, and use them for both flooding and LSAs.

5.4.1.1.  Default LSA Flooding Algorithm
...
  "3.  The LSA MUST be retransmitted over all OSPFv3 interfaces of types
       other than OSPFv3 MANET interface.

   4.  If the sending OSPFv3 interface is a Flooding-MPR selector of
       this router, then the LSA MUST also be retransmitted over all
       OSPFv3 MANET interfaces concerned by the scope, with the
       multicast address all_SPF_Routers."

# Comment 1. Since Flooding-MPRs are selected per interface, and since
the 2-hop neighbor set (N2) is also defined per interface, there is no
guarantee that a router that is 2 hops away, but requires using a
different MANET interface for the 2nd hop, is reachable via an MPR.
Thus, the above steps do not guarantee that all routers will be reached.
For example, consider two MANET interfaces A and B, where A forms a
network with diameter 1 and thus has no MPRs.  Then an LSA originated by
a router that uses only interface A will not reach a router that uses
only interface B.  Unless I am mistaken, this needs to be fixed.

5.2.7.  Hello Packet Processing

# Comment 2. It is not clear how N2 and the Flooding-MPR selector set
and Path-MPR selector set are updated when a Hello is received, since
details are not provided.  For example, if the router receives a Hello
from neighbor j, and the Hello does not list a symmetric 2-hop neighbor
k, then does the router immediately delete k from N2, or does it wait
until the tuple expires?  (Waiting seems unnecessary and would slow
down response to link failures.)
Similarly, if the router receives a Hello from a Flooding-MPR selector,
and the Hello does not list the router as a Flooding-MPR, does the
router immediately delete the neighbor from the Flooding-MPR selector
set, or does it wait until the tuple expires?

Also, when a Hello packet is received, the S bit (for Synch router)
needs to be examined to update a corresponding neighbor variable
(which is not specified in the draft).
Each router must know whether each neighbor is a Synch router,
in order to know when to change the neighbor state to ExStart.

Section 5.3.  Adjacencies

# Comment 3. Need to add that a Synch router must bring up adjacencies
with all neighbors AND each router must bring up an adjacency with a
neighbor that is a Synch router.  But "bring up adjacency" might be
too informal and imprecise.  A more precise statement would say when
the neighbor state must transition to ExStart.
For example, if a neighbor in state 2-Way has the S bit set
in its PMPR TLV, then the state must transition to ExStart.

Section 5.3.2.  Adjacency Conservation
...
  "When a router receives Hello packets from a symmetric 1-hop neighbor
   which ceases to list this router as being adjacent (see
   Section 5.2.3), ..."

# Comment 4. Section 5.2.3 does not mention adjacent neighbors, so I
think this should be "Section 5.2.6".

Section 5.4.  Link State Advertisements

# Comment 5. To avoid routing loops, it is also necessary to originate
a new router-LSA when the metric changes for an advertised neighbor,
even if the Path-MPR set does not change.
(Or you could just say that any change that affects the router-LSA
contents causes a new router-LSA to be originated).

Section 5.4.1.  LSA Flooding

# Comment 6. This section specifies how to flood an LSA that is
received from a neighbor, but not how to flood an LSA that is
originated by the router itself. If this is the same as RFC2328 and
RFC5340, then that should be stated.

   "3.  If the scope of the LSA is link local or reserved, the LSA
        MUST NOT be flooded on any interface."

# Comment 7. This implies that a link-LSA is forwarded only one hop
on a MANET.  Therefore, the link-LSA is flooded reliably only to
adjacent neighbors, not to neighbors in state 2-Way.
But link-LSAs are used to advertise link-local IPv6 addresses
for use in the next-hop calculation, so link-LSAs need to be
flooded reliably to all bidirectional neighbors.
Therefore, if Step 3 above is used, then link-LSAs are not
of much use in MANETs.  Maybe the best solution is to
not use link-LSAs for MANET interfaces.  Instead the next-hop
address can be obtained from the IPv6 source address in the
neighbor's Hello packet (as mentioned in RFC5340 Section 4.8.2).

5.7.  Routing Table Computation

  "When routing table (re)computation occurs, in addition to the
   processing of the Link State Database defined in [RFC5340] and
   [RFC2328], routers which have one or more MANET interfaces MAY
   include links between themselves and MANET neighbors that are in
   state 2-Way or higher (as data and protocol packets may be sent,
   received and processed over these links too)."

# Comment 8. First of all, by making it optional to include these links
to MANET neighbors, you do NOT ensure that the computed paths will be
shortest.  In fact, since some routers may not have any Path-MPRs
(consider a network with diameter 1), the router-LSA can be empty, and
the SPF calculation would not even calculate a path to 1-hop neighbors.
Therefore, "MAY" should be changed to "MUST".
Also, For clarity, you should explain that bidirectional neighbors
must be included even if they are not advertised in the router-LSA.

# Comment 9. The phrase "include links" is vague.  The description should
be more precise, explaining for example what the root vertex looks like
and that Step 2b (checking for a link from W back to V) must be skipped
when V is the root vertex and W is not advertised.

Richard

P.S. I noticed that the Metric TLV (appended to each Hello) includes
the cost of all neighbors on all MANET interfaces (not just the
interface on which the Hello is sent).
This can increase overhead significantly, but I see that it is
necessary because of the use of Path-MPRs to decide which neighbors
to advertise in the router-LSA.  I.e., each router needs to know
the minimum cost from each 2-hop neighbor even if the 2nd hop uses
a different interface.
The min-cost LSA method of OSPF-MDR does not require this.
In OSPF-MDR, a Hello (or LLS TLV attached to it) never includes
neighbors that are on a different interface.
_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: Abhay Roy <[email-masked]>
Date: Tue, 04 Nov 2008 12:02:48 -0800

Last call has completed.

Emmanuel will refresh the draft with the comments he received.

Regards,
-Abhay

On 10/21/2008 8:42 AM, Abhay Roy wrote:
> We are starting WG Last Call of this revision of the subject draft.
> 
> This drafts is intended to be Experimental status. The OSPF WG last call
> will begin today and will end at 12:00 AM EDT, Nov 4th, 2008.
> 
> Abhay/Acee
> 
> On 10/1/2008 2:30 PM, [email-masked] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Open Shortest Path First IGP Working 
>> Group of the IETF.
>>
>>     Title        : OSPF MPR Extension for Ad Hoc Networks
>>     Author(s)    : E. Baccelli, P. Jacquet, D. Nguyen, T. Clausen
>>     Filename    : draft-ietf-ospf-manet-mpr-02.txt
>>     Pages        : 30
>>     Date        : 2008-10-1
>>     
>> This document specifies an OSPFv3 interface type tailored for mobile
>>    ad hoc networks.  This interface type is derived from the broadcast
>>    interface type, and denoted the "OSPFv3 MANET interface type".
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-ospf-manet-mpr-02.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>>
>> ------------------------------------------------------------------------
>>
>> I-D-Announce mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt