Hi Vishwas, I am having hard time understanding the use case when one of the "new" TLVs someone invents will ask all receivers to stop process all the "old" TLVs. I propose we wait for such innovations to come down the line v/s try to sneak something in here at last call..
Also, lets take the ISIS discussion to isis working group.. Regards, -Abhay On 02/18/08-0800 at 12:17pm, Vishwas Manral writes: > Hi Abhay, > > Yes, LLS is optional. However we can ask for behaviors like do not > look at the LLS packet itself if you do not recognize the TLV and we > will have optional behavior, by just using 1 bit (which anyway may not > have been used). > >> 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. > Correct and they had to take the drastic measure of using a different > address. If they again have another feature where they do not want > connections to be formed for a particular TLV they will need another > address again. If they had just had a bit in the TLV to say, do not > look at the packet/ ignore the TLV if the TLV is unrecognized, the > behavior would just be adding a new TLV. This is very normal in most > new protocols - check the LDP RFC5036. Note that not much changes for > current implementations as such. > > Thanks, > Vishwas > > On Feb 18, 2008 12:12 PM, Abhay Roy <[EMAIL PROTECTED]> 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
