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

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 04 Nov 2008 16:48:19 +0100

Hi Richard,
Thanks for you feedback. I will comment inline

Richard Ogier a écrit :
> > 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.
> >

Actually there is no change from version 01 to version 02 on that
aspect. Version 01 was already specifying one MPR set per MANET
interface, except it was not stated that explicitly in the specification.

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

MPR flooding basically works as in OLSR, which works fine ;) However
your comment points out that it is not clear enough in the draft that N2
contains all the 2 hop neighbors advertized in Hellos, including 2 hop
neighbors appended in the TLVs. So we will add a sentence making this
clearer.

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

As per 5.2.7, N and N2 are updated to reflect Hellos as they are
received. If N or N2 has changed, the Flooding-MPR and Path-MPR sets
must be recomputed. If I understand correctly, your comment is about
when to delete stale info from repositories to reflect new Hello info.
Deletion is of course supposed to happen immediately. So we will add a
sentence that spells this out.

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

This is specified in section 5.6, which details the use of the S bit in
TLVs appended to Hellos. If a router starts receiving hellos with the S
bit set from a neighbor, it must go to ExStart with this neighbor.

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

Again, this is specified in section 5.6. However, we will add a sentence
which spells out "bringing up adjacency" into "transition into ExStart",
which is indeed more precise.

> >
> > 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".
> >

Actually 5.2.3 specifies how adjacencies are signalled in Hellos (via
node ordering in Hellos).

> >
> > 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).
> >

You are right. We will add the sentence you suggest here.

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

Originating a flood happens as usual: out all interfaces concerned by
the scope. We will add a sentence that spells this out.

> >   "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).
> >

You are right, Link-LSAs are not used in MPR-OSPF.

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

Yes, we will add a sentence that is more precise. You are right this is
a MUST and not a MAY, if shortest paths are wanted.

> > # 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.
> >

We will replace "include links" by a more precise expression, that will
make it clearer that the connectivity matrix used to compute routes
takes into account the links between the root and all its neighbors in
state 2-Way and higher.

cheers,
Emmanuel

> > 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
> >
> >

_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: Richard Ogier <[email-masked]>
Date: Tue, 04 Nov 2008 21:52:18 -0800

Emmanuel,

I have a few responses below.

>neighbors appended in the TLVs. So we will add a sentence making this
I see.  That means the router must also look at the Metric TLV or
PMPR TLV to determine N2.  This was not clear in the draft.

>bit set from a neighbor, it must go to ExStart with this neighbor.
Section 5.6 does NOT state that if a router starts receiving Hellos with
the S bit set, it must go to ExStart with the neighbor.
But I assume you will add this either to Section 5.6 or 5.3.

Also, you need to maintain a neighbor variable for the S bit, in order
to always know whether each neighbor is a Synch router.  This is needed
in Section 5.3.2 (Adjacency Conservation), since the second paragraph
requires the router to know whether or not a neighbor is a Synch router.

>node ordering in Hellos).
Section 5.2.3 specifies that Flooding-MPRs must be listed before all other
symmetric neighbors.  But this certainly does not indicate which neighbors
are adjacent.  As stated in the first paragraph of 5.3.2, a neighbor
may continue to be adjacent even if it is no longer an MPR or MPR selector
(or Synch router).  So your response is not correct.

After looking at Section 5.2.6 more closely, the PMPR TLV also might
not provide the required information, since it indicates which neighbors
are adjacent over any MANET interface, but does not indicate which
interface (if there are multiple interfaces).
But I don't think this makes the protocol incorrect, since it may be
OK for an unnecessary adjacency to be unidirectional (i.e., router A
still considers router B to be adjacent even after Router B has torn
down the adjacency).
My suggestion is to use the PMPR TLV anyway, so that the router tears
down the adjacency if the PMPR TLV from the neighbor does not list
the router as adjacent (over any interface).

Or, you can modify the Flooding-MPR Selection TLV by using the
8-bit Reserved field to indicate the number of adjacent neighbors
that are not MPRs.  Although this does not indicate which MPR neighbors
are adjacent, this may not be necessary since such an adjacency will
be re-established if it fails in either direction.

Cheers,
Richard

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 04 Nov 2008 20:01:46 +0100

Hi Richard, thanks. See below.

> But I assume you will add this either to Section 5.6 or 5.3.

Section 5.6 specifies that a synch router must bring up adjacencies with
all its MANET neighbors. To be more precise, we will add a sentence that
will make clear that "bring up adjacency" means "go to state ExStart".
We will also add a sentence like "If a router receives from a neighbor
Hellos with the S bit set, it must transition to Exstart with this
neighbor.". This was not explicitly stated so far, you are right.

> requires the router to know whether or not a neighbor is a Synch router.

Synch routers know they are Synch routers so they transition into
ExStart. And on the otehr hand, neighbors receive Hellos with the S bit
set, so they also transition into ExStart. It works OK this way. This
will indeed be clearer with the above explicit sentence we are going to
add in Section 5.6.

> be re-established if it fails in either direction.

Yes, the PMPR-TLV appended at the end of each hello lists which
neighbors are adjacent, and which neighbors are not, as per section
5.2.6. You are correct. So we will change the reference to 5.2.6, as you
suggest.

cheers
Emmanuel

---

From: Richard Ogier <[email-masked]>
Date: Tue, 04 Nov 2008 23:46:38 -0800

Emmanuel,

Thanks. I agree with your responses and have no further comments.

Richard