I agree. Acee On Feb 18, 2008, at 3:12 PM, Abhay Roy wrote: > On 02/18/08-0800 at 11:57am, Vishwas Manral writes: > >> Hi Abhay/ Leim, >> >>>> 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. >> I would think now that we have defined TLV's, we could add >> information >> like first bit telling what to do with the packet (LLS part of the >> packet) if the TLV is not . > > Hmm.. TLV having bits on what to do with the packet? Given > that LLS is optional, I am afraid, it can't be used to have > policies which end up dropping the packet. > > So I think we are OK with just adding the verbiage about > ignoring unknown TLVs. > >> I just noticed a draft in ISIS today (Multi Instance), which is using >> a different set of addresses because there is no way in the TLV to >> signal that in case you do not understand it drop the packet (and in >> case of the wrong packet being communicated there will be issues). > > ISIS is trying to add Instance ID's like OSPFv3 has. And > since it didn't have it from day one in the base packet > header, we came up with the IID TLV solution. > > Regards, > -Abhay > >> If we had just had the bits in the TLV properly used in >> IS-IS we could have a simple addition to make the thing >> work in all cases. It doesnt spoil anything to do some >> work which may not create a problem for now, but may be >> helpful in the future. >> >> There are however other issues in IS-IS as the TLV type >> and length fields are heavily constrained. >> >> Thanks, >> Vishwas >> >>> 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
