Hi Vishwas, On Feb 15, 2008, at 2:37 PM, Vishwas Manral wrote:
> 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. You're missing the point that LLS is optional. There will be routers that don't support LLS that will process packets independent of what TLVs that are sent. Hence, there shouldn't be OSPF routers that understand LLS that drop the OSPF packet contingent on not understanding an LLS TLV. > 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. This doesn't come for free. What types of things do you see LLS being used to signal on the other packet types? The same or different as hello and DD? This is for one hop signaling. > >>> 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. Ok - what are they? A cryptographic HMAC hash is likely to be stronger than the standard inet checksum. The only advantage I can see is that you'll know the when there is a checksum error rather than an authentication failure. IMHO, doing both just for this advantage isn't a very good engineering trade-off at all. Sort of like taking both a bath and a shower on the hopes you might get a little cleaner. Acee > 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
