Hi Liem, Like I gave the example of Opaque LSA's where we created an Opaque mechanism which could be used for all packets, I envision that the LLS would be a general mechanism to add additional information to the OSPF header, just like Opaque LSA's allowed further information exchanged.
Thanks, Vishwas On Feb 18, 2008 10:52 AM, Liem Nguyen <[EMAIL PROTECTED]> wrote: > Hi Vishwas, > > > Vishwas Manral wrote: > >>>>> 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. > >> > > All OSPF packets are one hop signaled, unlike IS-IS, where the same > > LSP needs to be flooded through the domain. > > > > > > Given that the Options field is primarily useful in Hello and DBD > packets (which is required to convey > the presence of LLS block), I see no benefit in having LLS in other > packet types. > > Thanks, > Liem > _______________________________________________ OSPF mailing list [email protected] http://www.ietf.org/mailman/listinfo/ospf
