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

["Acee Lindem (acee)" <[e-mail]>]

Hi Julien, 

On 2/18/16, 11:47 AM, "OSPF on behalf of Julien Meuric"
<[e-mail] on behalf of [e-mail]> wrote:

>Hi Peter,
>
>Feb. 17, 2016 - [e-mail]:
>> Hi Julien,
>>
>> On 2/16/16 18:24 , Julien Meuric wrote:
>>> Hi Pete,
>>>
>>> I believe the new text in the section 5 of the aforementioned I-D is a
>>> nice improvement for the specification (thank you Chris).
>>>
>>> However, the current version still says "TE will use the information in
>>> the TE Opaque LSA and the non-TE applications will use the information
>>> in the OSPFv2 Extended Link Opaque LSA". Then remote LFA joins the
>>> party, and I wonder if it is a "TE application" or not.
>>
>> clearly it is not.
>
>[JM] OK
>
>>
>>> As "there is no
>>> IETF specification documenting" what would strictly fall under "TE
>>> application" or "non-TE application", and even no real need to define a
>>> strict boundary, I consider that sentence as over-specification and
>>> suggest to jusst drop it.
>>
>> LFA has nothing to do with TE, it's obvious.
>
>[JM] I tend to agree on that, though not fully on the "obvious".
>
>>
>> And yes, we need a strict boundary between what is TE related and what
>> is not. If we don't define it, then every implementation can choose what
>> LSA to use, which would lead to the interoperability problems. The
>> purpose of this draft is to define a single mechanism to advertise link
>> attributes for non-TE applications.
>
>[JM] Yes, each application specification should state where among OSPF
>LSAs it gets these link parameters from. But it does not require to
>split application space between TE and non-TE:
>- applications per se should not be concerned about that split, this is
>protocol-related and should be addressed at the end of the specification
>chain (i.e., "this parameters is to be used for...", not "this use case
>falls into category X");
>- this is OSPF-specific: when considering IS-IS, this is not an issue;
>- the LFA example already contradicts the rule you suggest, tempering
>the backward compatibility text could avoid this situation.
>
>>
>>> That would let applications themselves look
>>> for that information where relevant/specified, whether they
>>> philosophically feel like being TE or not.
>>
>> TE application MUST only look at the TE Opaque LSA - that is specified
>> already.
>
>[JM] I would be cautious on "only". E.g., RFC 7770 can be applicable,
>though not TE.
>
>>
>> Non-TE application SHOULD look at Extended Link LSA - that is what we
>> want to specify in this draft.
>
>[JM] I am still confused with this "TE/non-TE application" rough
>summary, but I think we could find an agreement by saying that opaque
>LSAs (including TE) are to be used by so-called "TE application", and
>that extended link LSA should be preferred by the others.
>
>>
>>>
>>> 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? 

Thanks,
Acee




>
>Thanks,
>
>Julien
>
>>
>> thanks,
>> Peter
>>
>>>
>>> Cheers,
>>>
>>> Julien
>>>
>>> .
>>>
>>
>
>_______________________________________________
>OSPF mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ospf