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

Peter Psenak <> Wed, 17 February 2016 10:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4F98D1B3881 for <>; Wed, 17 Feb 2016 02:25:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.507
X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KXNoi0POfolb for <>; Wed, 17 Feb 2016 02:25:21 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 207661B388A for <>; Wed, 17 Feb 2016 02:25:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2255; q=dns/txt; s=iport; t=1455704721; x=1456914321; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=UuDsaoyz/+P1UoU40P6QKx8H532lPCL4D7EAoeX2/IA=; b=HiHdfqe0/6RracWT+rH7ESRz7IEWsnksdfFBWL9lGKofOYua7+v1+60o 3Y2F0TiYNS7ZDnhCumHJJYqOOog6NSVuTZKDpP75LvQiKQTG5zYc7WyTb VfoJhpQWAxDXOAOy1B1x0Kpvlgcr8Zyue7hin6nHjsiSKQUV6bb4gGrIG Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.22,459,1449532800"; d="scan'208";a="635549580"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2016 10:25:18 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id u1HAPI8V016805; Wed, 17 Feb 2016 10:25:18 GMT
Message-ID: <>
Date: Wed, 17 Feb 2016 11:25:18 +0100
From: Peter Psenak <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Julien Meuric <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Wed, 17 Feb 2016 10:25:23 -0000

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.

> 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.

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.

> 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 

Non-TE application SHOULD look at Extended Link LSA - that is what we 
want to specify in this draft.

> 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 


> Cheers,
> Julien
> .