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

Julien Meuric <> Thu, 18 February 2016 15:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E45BF1B2AC0 for <>; Thu, 18 Feb 2016 07:48:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LP2lIlZtACqb for <>; Thu, 18 Feb 2016 07:47:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8D0C71AD190 for <>; Thu, 18 Feb 2016 07:47:59 -0800 (PST)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id AA2C5E30080; Thu, 18 Feb 2016 16:47:58 +0100 (CET)
Received: from (unknown []) by (Postfix) with ESMTP id 5373EE3007F; Thu, 18 Feb 2016 16:47:58 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Thu, 18 Feb 2016 16:47:58 +0100
To: Peter Psenak <>
References: <> <>
From: Julien Meuric <>
Organization: Orange
Message-ID: <>
Date: Thu, 18 Feb 2016 16:47:57 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
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: Thu, 18 Feb 2016 15:48:01 -0000

Hi Peter,

Feb. 17, 2016 -
> 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.

[JM] I tend to agree on that, though not fully on the "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.

[JM] Yes, each application specification should state where among OSPF 
LSAs it gets these link parameters from. But it does not require to 
split application space between TE and non-TE:
- applications per se should not be concerned about that split, this is 
protocol-related and should be addressed at the end of the specification 
chain (i.e., "this parameters is to be used for...", not "this use case 
falls into category X");
- this is OSPF-specific: when considering IS-IS, this is not an issue;
- the LFA example already contradicts the rule you suggest, tempering 
the backward compatibility text could avoid this situation.

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

[JM] I would be cautious on "only". E.g., RFC 7770 can be applicable, 
though not TE.

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

[JM] I am still confused with this "TE/non-TE application" rough 
summary, but I think we could find an agreement by saying that opaque 
LSAs (including TE) are to be used by so-called "TE application", and 
that extended link LSA should be preferred by the others.

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

[JM] We fully agree on that. To make sure this is not creating an 
ambiguity, you may rephrase as:
"If the same link attribute is advertised in both LSAs, the information 
packed in these LSAs by advertising routers MUST be identical."



> thanks,
> Peter
>> Cheers,
>> Julien
>> .