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

[Richard Ogier <[e-mail]>]

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 Cordero Fuertes wrote:

[e-mail]" type="cite">

...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 <[e-mail]>

> 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" target="_blank" rel="nofollow">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
>        [e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www.ietf.org/mailman/listinfo/ospf" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/ospf
> or, via email, send a message with subject or body 'help' to
>        [e-mail]
>
> You can reach the person managing the list at
>        [e-mail]
>
> 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" <[e-mail]>
> To: "'Acee Lindem'" <[e-mail]>
> Cc: OSPF List <[e-mail]>
> Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid
>        Interface
> Message-ID:
>        <
> [e-mail]>
>
> 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-" target="_blank" rel="nofollow">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/" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/rfc5449/
> > https://datatracker.ietf.org/doc/rfc5614/" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/rfc5614/
> > https://datatracker.ietf.org/doc/rfc5820/" target="_blank" rel="nofollow">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 <[e-mail]>
> To: OSPF List <[e-mail]>
> Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid
>        Interface
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu, May 12, 2011 at 10:06 PM, Henderson, Thomas R <
> [e-mail]> 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-" target="_blank" rel="nofollow">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/" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/rfc5449/
> > > https://datatracker.ietf.org/doc/rfc5614/" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/rfc5614/
> > > https://datatracker.ietf.org/doc/rfc5820/" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/rfc5820/
> > >
> >
> > I would be interested to work on this.
> >
>
>
> Count me in too!
>
> Emmanuel
>
>
>
> >
> > - Tom
> > _______________________________________________
> > OSPF mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ospf" target="_blank" rel="nofollow">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" target="_blank" rel="nofollow">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 <[e-mail]>
> To: Emmanuel Baccelli <[e-mail]>
> Cc: OSPF List <[e-mail]>
> Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid
>        Interface
> Message-ID: <[e-mail]>
> 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 <
> [e-mail]
> > > 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-" target="_blank" rel="nofollow">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/" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/rfc5449/
> > > https://datatracker.ietf.org/doc/rfc5614/" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/rfc5614/
> > > https://datatracker.ietf.org/doc/rfc5820/" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/rfc5820/
> > >
> >
> > I would be interested to work on this.
> >
> >
> > Count me in too!
> >
> > Emmanuel
> >
> >
> >
> > - Tom
> > _______________________________________________
> > OSPF mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ospf" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/ospf
> >
> > _______________________________________________
> > OSPF mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ospf" target="_blank" rel="nofollow">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" target="_blank" rel="nofollow">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 <[e-mail]>
> To: "Retana, Alvaro" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>,
>        "[e-mail]" <[e-mail]>, "[e-mail]"
>        <[e-mail]>,     "[e-mail]" <[e-mail]>
> Subject: Re: [OSPF] Adoption of "OSPF Stub Router Advertisement"
>        (rfc3137bis) as WG Document
> Message-ID: <[e-mail]>
> 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" target="_blank" rel="nofollow">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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ospf" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/ospf
>
>
>
> ------------------------------
>
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf" target="_blank" rel="nofollow">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" target="_blank" rel="nofollow">http://www.ietf.org/mail-archive/web/ospf/attachments/20110516/e0f257c4/attachment.htm>

------------------------------

_______________________________________________
OSPF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ospf" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/ospf


End of OSPF Digest, Vol 63, Issue 11
************************************

_______________________________________________
OSPF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ospf" rel="nofollow">https://www.ietf.org/mailman/listinfo/ospf