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."
Thanks,
Julien
thanks,
Peter
Cheers,
Julien
.
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
