Hi Vishwas,
I suppose I should let the authors respond first but here are my
thoughts (speaking as a WG member).
On Feb 15, 2008, at 12:41 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.
>
> 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 :^).
>
> 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.
> 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.
Agree - it should be written to cover further authentication mechanisms.
>
> 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.
A statement along these lines should be included as well.
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
