Hi Julien, On 2/18/16, 11:47 AM, "OSPF on behalf of Julien Meuric" <[email protected] on behalf of [email protected]> wrote:
>Hi Peter, > >Feb. 17, 2016 - [email protected]: >> 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 >[email protected] >https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
