Subject: [OSPF] Comments on draft-retana-ospf-manet-single-hop-01

From: Juan Antonio Cordero Fuertes <[email-masked]>
Date: Mon, 16 May 2011 00:28:56 +0200

...sorry for not changing the subject.

Juan Antonio

> Hi Alvaro,
>
>
>
> Some comments/thoughts/questions about
> draft-retana-ospf-manet-single-hop-01
> below. Thanks in advance for your attention.
>
>
>
> 0) The position of routers in the networks addressed in this interface, is
> fixed or may move as long full connectivity (1-hop) remains? In section 6
> it
> is said that these are fixed networks, but this characteristic is not
> listed
> when describing single-hop broadcast networks in section 1.1.
>
>
>
> *About Hellos:*
>
>
>
> 1) Incremental Hellos are not used (required) in this proposal. However, in
> a single-hop MANET, (full) Hellos of any router list all routers in the
> network every HelloInterval seconds. Since the topology is static (not
> considering wireless link failures or changes in the link cost), may it be
> worth to explore a Hello optimization mechanism? Not only incremental
> Hellos
> but also, possibly, differential Hellos as specified in RFC 5614.
>
>
>
> *About Smart Peering:*
>
>
>
> 2) The proposed heuristic in section 3, is expected to replace or to
> complement the one presented in RFC 5820? Might be useful to make it more
> explicit. I assume that the proposed heuristic comes right after the one in
> RFC 5820 -- otherwise the number of adjacency-forming processes might be
> higher, some of them redundant. Is that correct?
>
>
>
> 3) Wait Time[r] mentioned in section 3 is defined in RFC 2328 as
> RouterDeadInterval. Why tying the waiting time before running the SP state
> machine to such RouterDeadInterval value? Wouldn't HelloInterval be
> sufficient? If the goal is to ensure that the router has information about
> all neighbors from the network, a user-configurable parameter within the
> interval [HelloInterval, RouterDeadInterval] may be useful.
>
>
>
> 4) If I'm understanding correctly, the number of adjacencies maintained by
> a
> router may be higher than the parameter "maximum number of adjacencies".
> Consider for instance MAX_ADJ=2 and 4 routers in a single-hop MANET with
> ids
> (actually, (RtrPri,RtrId)) 1,2,3,4, that appear in the network (are
> discovered) in order 4-3-2-1: 4 has three adjacencies. Seems that the
> "maximum number of adjacencies" corresponds to the number of REQUESTED
> adjacencies for a router, which is <= than the final number of adjacencies,
> given that routers accept passively any adjacency-forming request.
>
>
>
> 5) It is not clear for me in which sense the proposed heuristic is
> deterministic. Consider again a 4 nodes single-hop network with ids
> 1,2,3,4.
> Depending on the order of appearance, the adjacency subgraph changes (e.g.,
> for an appearance order 1-2-3-4 the adjacencies 12, 23, 34 are formed; for
> the appearance order 4-3-2-1 the formed adjacencies are 14, 24, 34). That
> is, the adjacency map cannot be extracted from the final topology of the
> network.
>
>
>
> *About Unsynchronized adjacencies:*
>
>
>
> 6) From section 4, it is not clear whether the use of unsynchronized
> adjacencies is required, possible, not necessary or not acceptable. In my
> understanding, they are required for correct operation of the interface.
> Not
> only for flooding issues, as detailed in the text, but also for shortest
> paths computation. If all bidirectional neighbors (thus, adjacencies +
> unsynch.adj.) are not listed in LSAs, the Shortest Path Tree is computed on
> a pretty fictional and suboptimal topology -- even in a higher degree than
> in original RFC 5820. Both reasons (flooding in control plane and SPT in
> data plane) justify the mandatory use of u.a. in this interface.
>
>
>
> *More general considerations:*
>
>
>
> 7) Seems to me that the mechanisms presented in this draft, while described
> as generalizations of RFC 5820, may be applied as well to other extensions,
> e.g. RFC 5449. Specific mechanisms from OR/SP are either discarded or
> severely adapted: Incremental Hellos are not used, Smart Peering is
> (re)defined in a way such that a new router selects only one existing
> router
> for synchronization, and the use of unsynchronized adjacencies corresponds
> to taking into account bidirectional neighbors in Router-LSAs. Maybe it is
> worth to describe an general interface to which existing extensions should
> converge when running in these single-hop bc networks?
>
>
>
> 8) *Behavior of MPR-OSPF in single-hop bc networks.* The use of the
> MPR-OSPF
> MANET interface in the single-hop bc leads to a behavior pretty similar to
> the one specified in the draft. As no MPRs will be elected (because there
> are no 2-hop neighbors), the only adjacencies will be those performed by
> the
> synch router -- by definition, there is only a synch router in the network,
> and its election (based on the router id) is similar to the heuristic
> proposed in section 3. Router-LSAs would only describe Path-MPRs, but the
> SPT would be computed correctly (i.e., not suboptimally) due to the fact
> that routers use all their 1-hop and 2-hop neighbors when running
> Dijkstra's. Finally, Router-LSAs would be processed and installed
> regardless
> on whether they come from an adjacent neighbor or not; all LSAs coming from
> bidirectional neighbors are processed in MPR-OSPF. None of such LSAs would
> be forwarded at any time, since they cannot come from an MPR selector.
>
>
>
> 9) Even when this may be out of scope, some central aspects of OSPF are
> clearly useless in networks such as the ones addressed in this draft. The
> existence of Hello and LSA messages, for instance, makes sense when there
> are two scopes (local and multi-hop global). For networks in which all
> routers are neighbors, one of both mechanisms could be not used. Hellos are
> necessary for establishing bidirectional communication. The only
> information
> that LSA may provide (and not Hellos) is link costs. Why not consider the
> inclusion of such information in Hellos, as in RFC 5449? In this case, that
> would be sufficient for computing the SPT.
>
>
>
> 10) This applies as well, at some extent, to the use of adjacencies. Since
> LSAs are "heard" and processed from all bidirectional neighbors (and not
> only adjacent), the only interest of adjacent links is reliability of
> flooding and the exchange of local instances of the LSDB. Allowing a router
> to synchronize its LSDB with a neighbor may reduce the time required for
> acquiring the last topology updates. It should however be evaluated the
> cost
> in terms of overhead of keeping adjacencies for such synchronizing time
> reduction. If the network is fixed, then it may be acceptable; for some
> mobile scenarios (still single-hop broadcast), it may become excessive.
>
>
>
> Cheers,
>
>
>
> Juan Antonio Cordero
>
> Hipercom -- INRIA
>
>
>
> 2011/5/13 <[email-masked]>
>
> > If you have received this digest without all the individual message
> > attachments you will need to update your digest options in your list
> > subscription.  To do so, go to
> >
> > https://www.ietf.org/mailman/listinfo/ospf
> >
> > Click the 'Unsubscribe or edit options' button, log in, and set "Get
> > MIME or Plain Text Digests?" to MIME.  You can set this option
> > globally for all the list digests you receive at this point.
> >
> >
> >
> > Send OSPF mailing list submissions to
> >        [email-masked]
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >        https://www.ietf.org/mailman/listinfo/ospf
> > or, via email, send a message with subject or body 'help' to
> >        [email-masked]
> >
> > You can reach the person managing the list at
> >        [email-masked]
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of OSPF digest..."
> >
> >
> > Today's Topics:
> >
> >   1. Re:  Single Hop MANET versus Broadcast/P2MP Hybrid Interface
> >      (Henderson, Thomas R)
> >   2. Re:  Single Hop MANET versus Broadcast/P2MP Hybrid Interface
> >      (Emmanuel Baccelli)
> >   3. Re:  Single Hop MANET versus Broadcast/P2MP Hybrid Interface
> >      (Stan Ratliff)
> >   4. Re:  Adoption of "OSPF Stub Router Advertisement"
> >      (rfc3137bis) as WG Document (Acee Lindem)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Thu, 12 May 2011 13:06:36 -0700
> > From: "Henderson, Thomas R" <[email-masked]>
> > To: "'Acee Lindem'" <[email-masked]>
> > Cc: OSPF List <[email-masked]>
> > Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid
> >        Interface
> > Message-ID:
> >        <
> > [email-masked]>
> >
> > Content-Type: text/plain; charset="us-ascii"
> >
> > > Hence, the questions for the WG are:
> > >
> > >
> > >   1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp-
> > > 01.txt as a WG document?
> > >
> > > https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybrid-bcast-and-
> > > p2mp
> >
> > I have no objection.
> >
> > >
> > >   2. Do we wish to allow revisions of the OSPF MANET experimental RFCs
> > > to cover the single-hop case (and possibly minor corrections)?
> > >
> > > https://datatracker.ietf.org/doc/rfc5449/
> > > https://datatracker.ietf.org/doc/rfc5614/
> > > https://datatracker.ietf.org/doc/rfc5820/
> > >
> >
> > I would be interested to work on this.
> >
> > - Tom
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Thu, 12 May 2011 22:14:48 +0200
> > From: Emmanuel Baccelli <[email-masked]>
> > To: OSPF List <[email-masked]>
> > Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid
> >        Interface
> > Message-ID: <[email-masked]>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > On Thu, May 12, 2011 at 10:06 PM, Henderson, Thomas R <
> > [email-masked]> wrote:
> >
> > > > Hence, the questions for the WG are:
> > > >
> > > >
> > > >   1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp-
> > > > 01.txt as a WG document?
> > > >
> > > > https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybrid-bcast-and-
> > > > p2mp
> > >
> > > I have no objection.
> > >
> >
> >
> > +1
> >
> >
> >
> > >
> > > >
> > > >   2. Do we wish to allow revisions of the OSPF MANET experimental
> RFCs
> > > > to cover the single-hop case (and possibly minor corrections)?
> > > >
> > > > https://datatracker.ietf.org/doc/rfc5449/
> > > > https://datatracker.ietf.org/doc/rfc5614/
> > > > https://datatracker.ietf.org/doc/rfc5820/
> > > >
> > >
> > > I would be interested to work on this.
> > >
> >
> >
> > Count me in too!
> >
> > Emmanuel
> >
> >
> >
> > >
> > > - Tom
> > > _______________________________________________
> > > OSPF mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/ospf
> > >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> >
> http://www.ietf.org/mail-archive/web/ospf/attachments/20110512/738639c2/attachment.htm
> > >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Thu, 12 May 2011 16:20:21 -0400
> > From: Stan Ratliff <[email-masked]>
> > To: Emmanuel Baccelli <[email-masked]>
> > Cc: OSPF List <[email-masked]>
> > Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid
> >        Interface
> > Message-ID: <[email-masked]>
> > Content-Type: text/plain; charset="us-ascii"; Format="flowed";
> >        DelSp="yes"
> >
> > Yes on both questions.
> >
> > Regards,
> > Stan
> >
> > On May 12, 2011, at 4:14 PM, Emmanuel Baccelli wrote:
> >
> > >
> > >
> > > On Thu, May 12, 2011 at 10:06 PM, Henderson, Thomas R <
> > [email-masked]
> > > > wrote:
> > > > Hence, the questions for the WG are:
> > > >
> > > >
> > > >   1. Do we want to accept draft-nsheth-ospf-hybrid-bcast-and-p2mp-
> > > > 01.txt as a WG document?
> > > >
> > > > https://datatracker.ietf.org/doc/draft-nsheth-ospf-hybrid-bcast-and-
> > > > p2mp
> > >
> > > I have no objection.
> > >
> > >
> > > +1
> > >
> > >
> > >
> > > >
> > > >   2. Do we wish to allow revisions of the OSPF MANET experimental
> > > RFCs
> > > > to cover the single-hop case (and possibly minor corrections)?
> > > >
> > > > https://datatracker.ietf.org/doc/rfc5449/
> > > > https://datatracker.ietf.org/doc/rfc5614/
> > > > https://datatracker.ietf.org/doc/rfc5820/
> > > >
> > >
> > > I would be interested to work on this.
> > >
> > >
> > > Count me in too!
> > >
> > > Emmanuel
> > >
> > >
> > >
> > > - Tom
> > > _______________________________________________
> > > OSPF mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/ospf
> > >
> > > _______________________________________________
> > > OSPF mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/ospf
> >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> >
> http://www.ietf.org/mail-archive/web/ospf/attachments/20110512/a8c352b9/attachment.htm
> > >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Fri, 13 May 2011 09:59:42 -0400
> > From: Acee Lindem <[email-masked]>
> > To: "Retana, Alvaro" <[email-masked]>
> > Cc: "[email-masked]" <[email-masked]>,
> >        "[email-masked]" <[email-masked]>, "[email-masked]"
> >        <[email-masked]>,     "[email-masked]" <[email-masked]>
> > Subject: Re: [OSPF] Adoption of "OSPF Stub Router Advertisement"
> >        (rfc3137bis) as WG Document
> > Message-ID: <[email-masked]>
> > Content-Type: text/plain; charset="Windows-1252"
> >
> > All,
> > At the WG meeting, we tentatively agreed that this RFC 3137 revision is
> > needed in lieu of a separate document for OSPFv3 stub router. Is there
> > anyone opposed to this becoming a WG document? If there is not
> significant
> > opposition, we'll make it a WG document on Friday, May 20th (in one
> week).
> > Thanks,
> > Acee
> > On May 9, 2011, at 3:54 PM, Retana, Alvaro wrote:
> >
> > Hi!
> >
> > Following up on the WG meeting in Prague?
> >
> > http://tools.ietf.org/html/draft-retana-ospf-rfc3137bis
> >
> > We just published version -01.  The only change from -00 is an update on
> > the authors? contact information.
> >
> > This e-mail is the formal request for adoption as a WG document.  Just
> like
> > rfc 3137, the intended status is Informational.
> >
> > Thoughts/comments?
> >
> > Thanks!
> >
> > Alvaro.
> >
> >
> > _______________________________________________
> > OSPF mailing list
> > [email-masked]<mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/ospf
> >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > OSPF mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ospf
> >
> >
> > End of OSPF Digest, Vol 63, Issue 10
> > ************************************
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-archive/web/ospf/attachments/20110516/e0f257c4/attachment.htm
> >
>
> ------------------------------
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>
>
> End of OSPF Digest, Vol 63, Issue 11
> ************************************
>

---

From: Richard Ogier <[email-masked]>
Date: Mon, 16 May 2011 23:04:28 -0700

Juan,

Since you made some good comments for draft-retana and mentioned RFC
5614, I thought I would introduce the following update for RFC 5614
(OSPF-MDR) by addressing some of your comments as they would apply to
it.

http://www.ietf.org/id/draft-ogier-ospf-manet-single-hop-00.txt

Please see my comments below.

Juan Antonio Cordero Fuertes wrote:

Juan Antonio

Hi
Alvaro,

0) The position of routers in the networks addressed in this interface,
is

fixed or may move as long full connectivity (1-hop) remains? In section
6 it

*About Hellos:*

1) Incremental Hellos are not used (required) in this proposal.
However, in

considering wireless link failures or changes in the link cost), may it
be

I agree, and have included the option for differential Hellos in
the update for RFC 5614.

*About Smart Peering:*

complement the one presented in RFC 5820? Might be useful to make it
more

explicit. I assume that the proposed heuristic comes right after the
one in

The update for RFC 5614 describes two new procedures, both of which
are optional.  One is a new option for constructing LSAs for a
single-hop network, which is interoperable with the other LSA options
and is similar to draft-nsheth.  The other is a simplification of the
MDR selection algorithm for a single-hop network, which gives exactly
the same result as the original algorithm when the MANET is a
single-hop network (and is therefore interoperable with it).

RouterDeadInterval. Why tying the waiting time before running the SP
state

sufficient? If the goal is to ensure that the router has information
about

4) If I'm understanding correctly, the number of adjacencies maintained
by a

Consider for instance MAX_ADJ=2 and 4 routers in a single-hop MANET
with ids

adjacencies for a router, which is <= than the final number of
adjacencies,

When OSPF-MDR is run in a single-hop network with AdjConnectivity =
2, every non-MDR/BMDR router will have exactly two adjacencies (one
with the MDR and one with a BMDR).  The MDR will have n-1 adjacencies
(same as the DR in OSPF).

Depending on the order of appearance, the adjacency subgraph changes
(e.g.,

for an appearance order 1-2-3-4 the adjacencies 12, 23, 34 are formed;
for

the appearance order 4-3-2-1 the formed adjacencies are 14, 24, 34).
That

network.

I agree that the heuristic for draft-retana is not deterministic.
But the same is true for an OSPF broadcast network, since the first two
routers that appear will be the DR and BDR.

In OSPF-MDR, if one router has higher RtrPri than the others, it will
always be the MDR regardless of order of appearance.

Regards,

Richard

---

From: Richard Ogier <[email-masked]>
Date: Wed, 18 May 2011 12:23:31 -0700

I also have a few comments on draft-retana-ospf-manet-single-hop.

As Juan pointed out, if routers start one at a time, then using

(RtrPri, RID) won't help much unless the first or second router has

the largest value of (RtrPri, RID), since routers won't become adjacent

with the high priority router if they already have enough adjacencies.

One property of draft-retana is that there does not exist a router

(e.g., DR) that floods each LSA and is also adjacent with all other

routers, as in OSPF and the other proposals.  Having such a router is

a well-tested way to deliver LSAs reliably to all routers with minimal

delay.  It is not clear that the performance will be as good if such

a router does not exist.

Since draft-retana states that flooding should be enabled for

unsychronized adjacencies, I assume also that every router is a

non-active overlapping relay (OR).  That means that ANY router could

(re)flood an LSA after PushbackInterval if it does not hear an Ack

from every router.  (Note that all Acks are multicast, so I

assume that all routers process every received Ack.)

It was found in simulations several years ago that, if

PushbackInterval < RxmtInterval/2 (as required by RFC 5820) and

the number of routers is large, then several routers typically

reflood a given LSA, generating significant overhead.

(This was true even though an OR suppresses its transmission

when it hears another router reflood the LSA.)

I suppose this can be fixed by having only the router with the

largest value of (RtrPri, RID) be a non-active OR, and perhaps

also the router with the second largest value.

This would be like selecting a DR and BDR, and would be closer

to OSPF and the other proposals.

Regards,

Richard

Juan Antonio

Hi
Alvaro,

*About Hellos:*

*About Smart Peering:*

network.

adjacencies is required, possible, not necessary or not acceptable. In
my

understanding, they are required for correct operation of the
interface. Not

unsynch.adj.) are not listed in LSAs, the Shortest Path Tree is
computed on

a pretty fictional and suboptimal topology -- even in a higher degree
than

7) Seems to me that the mechanisms presented in this draft, while
described

as generalizations of RFC 5820, may be applied as well to other
extensions,

for synchronization, and the use of unsynchronized adjacencies
corresponds

to taking into account bidirectional neighbors in Router-LSAs. Maybe it
is

worth to describe an general interface to which existing extensions
should

MANET interface in the single-hop bc leads to a behavior pretty similar
to

the one specified in the draft. As no MPRs will be elected (because
there

are no 2-hop neighbors), the only adjacencies will be those performed
by the

synch router -- by definition, there is only a synch router in the
network,

proposed in section 3. Router-LSAs would only describe Path-MPRs, but
the

on whether they come from an adjacent neighbor or not; all LSAs coming
from

bidirectional neighbors are processed in MPR-OSPF. None of such LSAs
would

clearly useless in networks such as the ones addressed in this draft.
The

existence of Hello and LSA messages, for instance, makes sense when
there

routers are neighbors, one of both mechanisms could be not used. Hellos
are

that LSA may provide (and not Hellos) is link costs. Why not consider
the

inclusion of such information in Hellos, as in RFC 5449? In this case,
that

10) This applies as well, at some extent, to the use of adjacencies.
Since

flooding and the exchange of local instances of the LSDB. Allowing a
router

Cheers,

Juan Antonio Cordero

Hipercom -- INRIA

significant

> opposition, we'll make it a WG document on Friday, May 20th (in
one week).

> This e-mail is the formal request for adoption as a WG document.
Just like

-------------- next part --------------

URL: <http://www.ietf.org/mail-archive/web/ospf/attachments/20110516/e0f257c4/attachment.htm>

OSPF mailing list

[email-masked]

---

From: Richard Ogier <[email-masked]>
Date: Thu, 19 May 2011 10:31:01 -0700

I thought about why it might be best to have a single router
(e.g., DR) that floods each LSA and is also adjacent with all
other routers.  I think the following example shows that it is
best to have such a router (versus smart peering).

Consider a single-hop broadcast network with 3 routers having
RIDs 1, 2, and 3.  Assume 3 is adjacent to both 1 and 2.  If OSPF
(or draft-nsheth or OSPF-MDR) is used, router 3 will be the DR.
(Even though each router should have at least 2 adjacencies,
this uniconnected example will demonstrate my point.)

  3
 / \
1   2

Suppose router 1 floods an LSA, but none of the other routers
receive it.  Router 1 will retransmit the LSA to router 3
after RxmtInterval if either OSPF or draft-retana is used.
If OSPF is used, router 3 (the DR) will flood the LSA immediately
and router 2 will receive it.
However, if draft-retana (or RFC 5820) is used, router 3 will
not immediately forward the LSA (since it is not an MPR or
active OR), but will wait PushbackInterval plus jitter before
flooding the LSA.  This interval may be small (e.g., 2 seconds) but
as I mentioned in my last post, in large networks this mechanism
may result in several routers forwarding the same LSA unless
PushbackInterval is larger than stated in RFC 5820.

Suppose we fix this by having only one router/relay that
forwards the LSA when it is received from another router.
If, in the above example, that relay is router 2, then
it still would not work, since 1 is not adjacent with 2.
So the single relay must be router 3.  In general, the single
relay must be be adjacent with all other routers.
Therefore, one can conclude that it is best to have a special
router (e.g., DR) that is adjacent with all other routers.
Note that draft-retana does not have this property, and would have
to dispense with "smart peering" in order achieve this property.

Regards,
Richard