As long as we are discussing this draft, I've changed the subject line. Speaking as a WG member, my opinion is that this draft is not worth the complexity and I wouldn't implement it even if the WG choose to adopt it as a WG document. There are many places in RFC 2328 where a decision is made dependent on whether or not a neighbor is FULL and I don't think one can introduce this protocol change under the assumption that the current definition. For example, MAXAGE LSAs are handled differently dependent on whether or not any neighbors are in exchange state. This logic would need to be bifurcated to handle both types of exchange.
Additionally, the database exchange is only one component of separation between routing and non-routing information. The transport instance is superior in that it offers complete separation. See one more comment inline. On Nov 20, 2010, at 10:22 AM, Papadimitriou, Dimitri (Dimitri) wrote: > Glen, > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On >> Behalf Of Glen Kent >> Sent: Monday, November 15, 2010 4:16 PM >> To: [email protected] >> Subject: [OSPF] OSPF IETF Meeting >> >> (1) While i understand the need to speed up the OSPF adjacency >> formation process, i somehow dont think that the mechanism described >> in draft-dimitri-ospf-phased-db-sync-00.txt is good enough. It looks a >> little tenuous and appears unscalable. > > Can you please clarify what you mean with i) tenuous and ii) "appears > unscalable" wrt to what ? and why ? this could be helpful for the next > iteration of the document. > >> I would like to compare this >> vis-a-vis the transport mechanism that has been proposed by some other >> folks, since that too attempts to achieve the same thing. > > As stated during the meeting, if you do such comparison keep in mind > objectives and criteria. Indeed, partitioning instances is detrimental for > devices which uses OSPF for exchanging non-IP routing information but this is > the information from which they derive their forwarding entries. For > instance, with MPLS-TE, separate instances would delay the RSVP-TE LSP setup > (since relying on TE information). I disagree on two counts. 1. There is nothing that says the TE information has to moved to a separate instance. It is your draft that arbitrarily splits the database at the opaque LSA boundary. 2. You can not categorically say the transport instance will add delay. While the primary OSPF instance will normally be given priority, there is no reason delay will be added unless there are bottlenecks in the routing domain. Thanks, Acee > > > Thanks, > -d. >> (2) I support draft-yang-ospf-hiding-00.txt and i think its makes >> sense to progress this draft. >> >> (3) I also support draft-bhatia-manral-auth-trailer-ospfv3-01, and i >> think there clearly is a need to move away from IPsec security for >> OSPFv3. >> >> (4) I am not comfortable with >> draft-bhatia-karp-ospf-ip-layer-protection-00.txt, as it currently >> stands. While i understand that the author of this draft was one of >> the co-authors of RFC 5709, i would like to first understand the >> rationale behind introducing Apad in the crypto computation as has >> been described in 5709. Thats clearly not a part of the original HMAC >> specification. The authors have modified that without giving any >> explanation in 5709, and i think its best that we first understand why >> that change was introduced before we accept any changes (or >> enhancements if you will) to it. >> >> (5) draft-kini-ospf-fast-notification-00.txt looks interesting and i >> would like to see some more discussions on it. I dont think its >> currently at a maturity level where it can be progressed, but a >> discussion would nevertheless be good. >> >> Glen >> _______________________________________________ >> OSPF mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ospf >> > _______________________________________________ > OSPF mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
