Re: [OSPF] Comment on draft-ppsenak-ospf-te-link-attr-reuse-01

[Julien Meuric <[e-mail]>]

Hi Acee,

Feb. 20, 2016 - [e-mail]:
> Hi Julien,

[snip]

>>>> What is more, I really think that the current wording  is too loose in
>>>> "it is expected that the information in these LSA [sic] would be
>>>> identical". I do not see the drawback of having full alignment of
>>>> values
>>>> in case of duplication, but I see the operational risk of nightmare in
>>>> case they are not. As a result, I suggest to rephrase into: "If the
>>>> same
>>>> link attribute is advertised in both LSAs, the information in these
>>>> LSAs
>>>> MUST be identical."
>>>
>>> given the OSPF protocol operation above can not be guaranteed. LSAs
>>> arrive asynchronously and there can be intervals during which the
>>> consistency of the information between two different LSAs can not be
>>> guaranteed.
>>
>> [JM] We fully agree on that. To make sure this is not creating an
>> ambiguity, you may rephrase as:
>> "If the same link attribute is advertised in both LSAs, the information
>> packed in these LSAs by advertising routers MUST be identical."
>
> Are we sure on this? Today we can have an OSPF metric that is independent
> of the OSPF TE Metric - why wouldn’t we want the same flexibility with
> SRLG?

[JM] From my perspective, I concur. Metrics are purely administrative 
parameters: it makes sense to allow operators to use different routing 
decision between SPF and TE. Conversely, SRLGs are supposed to abstract 
the underlying infrastructure to enable diverse routing: this gives a 
clear semantic on the SRLG link parameter. I do not see any value in 
using two different infrastructure descriptions, while I see some risk 
of operational mess in case one forget to update one of the parameter sets.
I also believe that if double SRLG capability had been an operator's 
requirement, we would have started from there and confronted that to 
both IGPs. This is a different motivation here.

Cheers,

Julien


> Thanks,
> Acee
>
[snip]