Hi Acee, I like the generic mechanism talked about in the document. I however think the document does not describe how to treat TLV's if a TLV is not understood. If you see all other newer specs for example RFC5036 for LDP, you will notice they have the first 2 bits defining how to treat a packet if there is an unknown TLV.
The document says the block can only be attached to Hello and DD packets, I would prefer the signaling to be able to be attached to any packets. Thus making OSPF packets truly extensible. The document talks about not doing a checksum if the Crytographic security is present. I think it enhances security as well as simplifies code if we calculate the checksum in all cases. Also the document seems to think that MD5 is the only cryptographic authentication method present and explicitly mentions it. The same needs to be removed. Infact if we hear the view on MD5 it is closer to: * Use of MD5, ciphers with a strength of 56 bits or less should be avoided in almost all circumstances. Use of ciphers with key sizes of 64 bits or less should be discontinued as soon as is practicable. quoting from a mail in the SAAG list. Also as routers that do not understand LLS may receive the packets, we have to make sure to state that we need to take care changes made due to LLS block TLV's do not affect the basic routing when interacting with non-LLS routers. This will be a helpful guidance for any future extensions to LLS TLV's. Thanks, Vishwas On Fri, Feb 15, 2008 at 9:15 AM, Acee Lindem <[EMAIL PROTECTED]> wrote: > This starts the WG last call for the subject document. The target > status is Proposed Standard. > The WG last call will begin today and will end March 1st, 2008 at > 12:00 AM EST. Note that a previous revision (not including OSPFv3) of > this protocol extension was published as an experimental RFC 4813. > > Thanks, > Acee > _______________________________________________ > OSPF mailing list > [email protected] > http://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list [email protected] http://www.ietf.org/mailman/listinfo/ospf
