Hi Vishwas, Thanks for your comments. Please see inline:
On 02/15/08-0800 at 9:41am, Vishwas Manral writes: > 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. Looking at some previous TLV usage in OSPF specs (e.g. rfc3630), I think all we need to add is "Unrecognized TLV types are ignored." I will add this text in section 2.3. > 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. Initially we only wanted it in Hello packets. But then we found some use case for DD packets (rfc 4812). Sending LLS with any packet type is technically feasible, but would require separate documentation when such a need arises. I would prefer to not include it in here at this time, since there is no known use case. > 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. I will remove direct references to MD5, so that it's equally applicable to any available cryptographic authentication. > 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. Sure, I will add something to this effect.. Regards, -Abhay > 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 > _______________________________________________ OSPF mailing list [email protected] http://www.ietf.org/mailman/listinfo/ospf
