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). 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
