Dimitri, >> >> (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.
As per your draft you exchange the important information first followed by all ancillary stuff. Now, what you have not spelled out is whether SPF should get triggered or not when you do the first phase? If Yes, then you do delay doing the second phase as most OSPF tasks are monolithic and can only do one thing at a time. So, after some delayed time you start the subsequent exchanges, is this correct? Glen > >> 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). > > 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
