Hi Rob, Julien,
please see inline:
On 2/27/16 00:56 , Rob Shakir wrote:
Hi Acee, Peter, Julien,
On 23 February, 2016 at 12:06:10 PM, Acee Lindem (acee) (a...@cisco.com
<mailto:a...@cisco.com>) wrote:
##PP
I'm still not sure we want to enforce that even on the router that
generates these. Different apps may use different values of certain link
attribute. Take an SRLG as an example. You may have SRLG values on the
link used only by GMPLS/optical plane. These values have meaning only in
the context of the GMPLS/optical. You do not want LFA to use these
values, because their meaning is different and irrelevant for LFA, you
may define a different set of values used by LFA.
I tend to agree with Julien here, this sounds problematic from a
management perspective. If I something that is a physical property of
the link (which a SRLG is); and I run “TE” and “non-TE” applications on
my network - i.e., a LFA and RSVP-TE tunnels, then I now need to
maintain both the lists being identical, such that the extended link
attribute SRLG classification matches the TE attribute’s values. This
sounds complex (what happens when they get out of sync); with no huge
up-side to duplicating them. Even if we do want to have one application
work differently to another w.r.t SRLGs, then why would we not do this
with the policy that is used when making a path placement decision,
rather than by splitting them into different attributes?
IMHO, a nice solution here is that we have each set of information
maintained in one place in the protocol; if this has historically been
in the TE attribute, then I do not necessarily see a good reason to try
and move it. Going forward, we should discuss for new extensions whether
these attributes are solely useful for traffic engineering; or whether
they are more general purpose, Metric gives us a good example here - the
TE metric is *only* relevant to traffic engineering path placement,
whereas the metric is relevant to LFA, standard IP applications, and can
be relevant to TE.
I would also rather see this than duplicating the same content of
attributes across two different LSAs. This creates ambiguity as to which
one was actually used by the consuming application on the network
element for a particular protocol.
In general, enforcing the same values to be carried for the same link
attribute in two different LSAs may become a limitation in the future.
We already have a precedence with IGP/TE metric. At the end we are
talking about two independent LSAs/TLVs, we are just sharing the same
TLV format.
In terms of SRLG, there are real deployments, where optical plane uses
SRLGs that are associated with a larger areas like "city" or "district"
that are used for disaster recovery purposes and such values would have
not meaning in the context of the LFA - one would still want to use the
LFA that is in such SRLG.
There should be no ambiguity really - information carried in TE Opaque
LSA is used by TE/GMPLS application. What is carried in Extended Link
LSA is used by other applications.
thanks,
Peter
Best,
r.
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
