Re: [OSPF] WG Last Call for OSPF Link-local Signaling - draft-ietf-ospf-lls-04.txt

[Acee Lindem <acee at redback.com>]

Hi Vishwas,

On Feb 15, 2008, at 2:37 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.
> By having this we are forcing a behavior on future TLV's, they all
> have to be optionally understood. We cannot enforce a behavior of drop
> a packet if the TLV is not understood. By using the first 2 bits of
> the TLV's to signal this behavior we could get such behavior for the
> future. In my view such signalling may be possible in the future.

LLS is a backward compatible extension. Hence, we're not dropping  
packets based on understanding TLVs.



>
>>> 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.

I discussed this with on of the authors and if you are going to use  
LLS on other packet types, than it would probably be for a different  
set of things than we signal today. Hence, we're going to defer this  
until such signaling is required. I can't see putting this burden on  
the specification when we don't have a requirement.

Thanks,
Acee



>
>>> 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.
> I agree it is consistent. I however see no benefits in the  
> approach, though
> I can point out problems with it. If we are making a new standard  
> we could
> as well rectify the same.
>
>
> Thanks,
> Vishwas
>
>>
>>  Thanks,
>>  Acee
>>
>>
>>
>>
>>>
>>> Thanks,
>>> Vishwas
>>>
>>> On Fri, Feb 15, 2008 at 9:15 AM, Acee Lindem <acee at redback.com>  
>>> 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
>>>>  OSPF at ietf.org
>>>>  http://www.ietf.org/mailman/listinfo/ospf
>>>>
>>
>>

_______________________________________________
OSPF mailing list
OSPF at ietf.org
http://www.ietf.org/mailman/listinfo/ospf