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

Julien Meuric <julien.meuric@orange.com> Thu, 18 February 2016 15:48 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45BF1B2AC0 for <ospf@ietfa.amsl.com>; Thu, 18 Feb 2016 07:48:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.89
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LP2lIlZtACqb for <ospf@ietfa.amsl.com>; Thu, 18 Feb 2016 07:47:59 -0800 (PST)
Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0C71AD190 for <ospf@ietf.org>; Thu, 18 Feb 2016 07:47:59 -0800 (PST)
Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AA2C5E30080; Thu, 18 Feb 2016 16:47:58 +0100 (CET)
Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 5373EE3007F; Thu, 18 Feb 2016 16:47:58 +0100 (CET)
Received: from [10.193.71.204] (10.193.71.204) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Thu, 18 Feb 2016 16:47:58 +0100
To: Peter Psenak <ppsenak@cisco.com>
References: <56C35B58.8080301@orange.com> <56C44A8E.7010300@cisco.com>
From: Julien Meuric <julien.meuric@orange.com>
Organization: Orange
Message-ID: <56C5E7AD.4060508@orange.com>
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: <56C44A8E.7010300@cisco.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/XcrQqS9sHGbdj_Tq5QkXllTw6Zo>
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: [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: Thu, 18 Feb 2016 15:48:01 -0000

Hi Peter,

Feb. 17, 2016 - ppsenak@cisco.com:
> 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 
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,

Julien

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