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

[Rob Shakir <[e-mail]>]

Hi Acee, Peter, Julien,

On 23 February, 2016 at 12:06:10 PM, Acee Lindem (acee) ([e-mail]) 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.

Best,

r.