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

Rob Shakir <> Fri, 26 February 2016 23:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 92D6E1B33F6 for <>; Fri, 26 Feb 2016 15:56:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 33EE7aPhFTk5 for <>; Fri, 26 Feb 2016 15:56:53 -0800 (PST)
Received: from ( [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 400D21B33E3 for <>; Fri, 26 Feb 2016 15:56:52 -0800 (PST)
Received: from [] (helo=latte) by with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1aZSFL-0002Ii-47; Fri, 26 Feb 2016 23:56:31 +0000
Date: Fri, 26 Feb 2016 16:56:45 -0700
From: Rob Shakir <>
To: "Acee Lindem (acee)" <>, Julien Meuric <>
Message-ID: <etPan.56d0e63d.6d544cb5.111@latte>
In-Reply-To: <>
References: <> <> <> <> <> <>
X-Mailer: Airmail Beta (350)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="56d0e63d_66ff8e5a_111"
Archived-At: <>
Cc: OSPF WG List <>
Subject: Re: [OSPF] Comment on draft-ppsenak-ospf-te-link-attr-reuse-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Feb 2016 23:56:55 -0000

Hi Acee, Peter, Julien,

On 23 February, 2016 at 12:06:10 PM, Acee Lindem (acee) ( wrote:

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.