Hi Abhay, The IS-IS talk was just to learn lessons in OSPf from other protocols which in this case is IS-IS.
Thanks, Vishwas On Feb 18, 2008 1:07 PM, Abhay Roy <[EMAIL PROTECTED]> wrote: > 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
