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

[Juan Antonio Cordero Fuertes <[e-mail]>]

...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
> >
> > 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
> > 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-
> > > 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 <[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-
> > > > 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
> > > [e-mail]
> > > 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 <[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-
> > > > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/ospf
> > >
> > > _______________________________________________
> > > OSPF mailing list
> > > [e-mail]
> > > 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 <[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
> >
> > 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
> >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > OSPF mailing list
> > [e-mail]
> > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf
>
>
> End of OSPF Digest, Vol 63, Issue 11
> ************************************
>