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. > > LLS is optional so the TLVs should have no impact on whether or not > the OSPF packet itself is accepted. The document probably should state: > > 1) That the described TLVs MUST be supported. > 2) What to do if an unknown TLV is encountered. The choices are: > a. Simply ignore it - this is what people have implemented. > b. Ignore the whole LLS block > c. Ignore the whole LLS block contingent on the type encoding > > I vote for a. By having this we are forcing a behavior on future TLV's, they all have to be optionally understood. We cannot enforce a behavior of drop a packet if the TLV is not understood. By using the first 2 bits of the TLV's to signal this behavior we could get such behavior for the future. In my view such signalling may be possible in the future.
> > 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. > > I think that since this is "Link-Local" signaling, hello and DD > packets make the most sense. In fact, at one time I had argued to > limit it to hellos but the authors said there were cases where > appending the signaling to the next DD would result in the signaling > being communicated faster. However, since a hello can safely be sent > at any time, I still feel limiting it to hello would be better :^). I do not see a reason to not allow LLS to packets other than Hello and DD. Its all about future extensibility here. We should try to be future proof by allowing the same. If a TLV is not expected in a packet it can anyway be ignored. > > 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. > > This is consistent to what is done for OSPF cryptographic > authentication for the packet itself. I see no reason not to do the > same for LLS or to effectively checksum it twice when authentication > is configured. I agree it is consistent. I however see no benefits in the approach, though I can point out problems with it. If we are making a new standard we could as well rectify the same. Thanks, Vishwas > > Thanks, > Acee > > > > > > > > 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
