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 protected]> > 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 protected] > > 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 protected] > > You can reach the person managing the list at > [email protected] > > 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 protected]> > To: "'Acee Lindem'" <[email protected]> > Cc: OSPF List <[email protected]> > Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid > Interface > Message-ID: > < > 7cc566635cfe364d87dc5803d4712a6c4ceed71...@xch-nw-10v.nw.nos.boeing.com> > > 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 protected]> > To: OSPF List <[email protected]> > Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid > Interface > Message-ID: <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > On Thu, May 12, 2011 at 10:06 PM, Henderson, Thomas R < > [email protected]> 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 protected] > > 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 protected]> > To: Emmanuel Baccelli <[email protected]> > Cc: OSPF List <[email protected]> > Subject: Re: [OSPF] Single Hop MANET versus Broadcast/P2MP Hybrid > Interface > Message-ID: <[email protected]> > 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 protected] > > > 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 protected] > > https://www.ietf.org/mailman/listinfo/ospf > > > > _______________________________________________ > > OSPF mailing list > > [email protected] > > 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 protected]> > To: "Retana, Alvaro" <[email protected]> > Cc: "[email protected]" <[email protected]>, > "[email protected]" <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" <[email protected]> > Subject: Re: [OSPF] Adoption of "OSPF Stub Router Advertisement" > (rfc3137bis) as WG Document > Message-ID: <[email protected]> > 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 protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/ospf > > > > ------------------------------ > > _______________________________________________ > OSPF mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ospf > > > End of OSPF Digest, Vol 63, Issue 10 > ************************************ >
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
