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