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

Peter Psenak <> Thu, 18 February 2016 22:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A0B391A1B45 for <>; Thu, 18 Feb 2016 14:36:29 -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 cyVKIA0yy2xL for <>; Thu, 18 Feb 2016 14:36:27 -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 2D6621A1AAD for <>; Thu, 18 Feb 2016 14:36:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5349; q=dns/txt; s=iport; t=1455834987; x=1457044587; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=X6LL1Tr/aXOp/YeI1b7wKvk/NYggboCqsu3oRYT63Bk=; b=FMZoiMrCNFilJOSxXKd8TJDnHfzEfb+OkO/b0FdDsKbLEAC3kgZebtYD RO9B+YCtXJ1Hdam//wvFo6qK+3PIek8fPW9GfinTt8jswbnwh61dkJqgz kPWeGQLvCQUF1g+7cmGv66+rf21uHk/fdsxxhEMy3DjBTgUw+Cvw7jNwT 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.22,467,1449532800"; d="scan'208";a="649421857"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Feb 2016 22:36:24 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id u1IMaOw6010901; Thu, 18 Feb 2016 22:36:24 GMT
Message-ID: <>
Date: Thu, 18 Feb 2016 23:36:24 +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: Thu, 18 Feb 2016 22:36:29 -0000

Hi Julien,

please see inline :(##PP)

On 2/18/16 16:47 , Julien Meuric wrote:
> 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.
> [JM] OK
>>> 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

let me disagree. Applications do not decide which LSAs to use. It's the 
protocol extension that is made for an application and application needs 
to follow it. And for TE application it has been done by RFC3630.

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

well, let's not get into that discussion here.

> - the LFA example already contradicts the rule you suggest, tempering
> the backward compatibility text could avoid this situation.

the text we added in the Backward Compatibility is not meant to 
standardized the non standard behavior by any means.

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

I do not see what RFC 7770 has to do with link attributes. RFC7770 is 
about advertising optional router capabilities, which is completely 
orthogonal to this draft.

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

Extended Link LSA is an Opaque LSA as well. You need to specify which 
Opaque LSA is to be used by TE and which for the rest of apps.

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

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.

In general, by mandating the same values in both LSAs we are creating an 
unnecessary limitation that I'm not convinced about.


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