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

Julien Meuric <julien.meuric@orange.com> Tue, 16 February 2016 17:24 UTC

Return-Path: <julien.meuric@orange.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id F00881B31B0 for <ospf@ietfa.amsl.com>; Tue, 16 Feb 2016 09:24:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.89
X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.006, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id PoJ_07iRbPoZ for <ospf@ietfa.amsl.com>; Tue, 16 Feb 2016 09:24:42 -0800 (PST)
Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0F6631B31AF for <ospf@ietf.org>; Tue, 16 Feb 2016 09:24:42 -0800 (PST)
Received: from p-mail1.rd.orange.com (localhost.localdomain []) by localhost (Postfix) with SMTP id 399AA41024C; Tue, 16 Feb 2016 18:24:41 +0100 (CET)
Received: from FTRDCH01.rd.francetelecom.fr (unknown []) by p-mail1.rd.orange.com (Postfix) with ESMTP id CDB9C41024B; Tue, 16 Feb 2016 18:24:40 +0100 (CET)
Received: from [] ( by FTRDCH01.rd.francetelecom.fr ( with Microsoft SMTP Server id; Tue, 16 Feb 2016 18:24:40 +0100
To: ppsenak@cisco.com
From: Julien Meuric <julien.meuric@orange.com>
Organization: Orange
Message-ID: <56C35B58.8080301@orange.com>
Date: Tue, 16 Feb 2016 18:24:40 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/9xvWXJy4mmhG7q7tJLmxFrU7-G0>
Cc: OSPF WG List <ospf@ietf.org>
Subject: [OSPF] Comment on draft-ppsenak-ospf-te-link-attr-reuse-01
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Feb 2016 17:24:43 -0000

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. 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. That would let applications themselves look 
for that information where relevant/specified, whether they 
philosophically feel like being TE or not.

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