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

[Julien Meuric <[e-mail]>]

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

Thanks,

Julien

>
> thanks,
> Peter
>
>>
>> Cheers,
>>
>> Julien
>>
>> .
>>
>