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. 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. LLS is a backward compatible extension. Hence, we're not dropping packets based on understanding TLVs. > >>> 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. I discussed this with on of the authors and if you are going to use LLS on other packet types, than it would probably be for a different set of things than we signal today. Hence, we're going to defer this until such signaling is required. I can't see putting this burden on the specification when we don't have a requirement. Thanks, Acee > >>> 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
