Re: [OSPF] Regarding draft-ppsenak-ospf-te-link-attr-reuse-00

Julien Meuric <julien.meuric@orange.com> Thu, 05 November 2015 08:12 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 968FC1A00B8 for <ospf@ietfa.amsl.com>; Thu, 5 Nov 2015 00:12:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.194
X-Spam-Level:
X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 yB_URHDxbeCT for <ospf@ietfa.amsl.com>; Thu, 5 Nov 2015 00:12:10 -0800 (PST)
Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id E252E1A0275 for <ospf@ietf.org>; Thu, 5 Nov 2015 00:12:07 -0800 (PST)
Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 95110A4426C; Thu, 5 Nov 2015 09:12:12 +0100 (CET)
Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 8CE8FA44245; Thu, 5 Nov 2015 09:12:12 +0100 (CET)
Received: from [10.193.116.76] (10.193.116.76) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.224.2; Thu, 5 Nov 2015 09:12:06 +0100
From: Julien Meuric <julien.meuric@orange.com>
To: Jeff Tantsura <jeff.tantsura@ericsson.com>
References: <D24CF2B7.37452%acee@cisco.com> <BLUPR05MB292E9628E4172C733C59BA8A9380@BLUPR05MB292.namprd05.prod.outlook.com> <5627CDF6.605@cisco.com> <BLUPR05MB292B99DA8B1B9E253A0E83BA9380@BLUPR05MB292.namprd05.prod.outlook.com> <5627F457.8020701@cisco.com> <BLUPR05MB2927E888C41831AF2786280A9270@BLUPR05MB292.namprd05.prod.outlook.com> <CAG4d1rctdk6QcrhjEj2n-1VM2HTzQJvFxgamneis+fsiH0rcTw@mail.gmail.com> <562917FE.6070100@cisco.com> <D252C136.384AC%acee@cisco.com> <E70EB200-09AE-464C-A0B2-38F480489F16@ericsson.com>
Organization: Orange
Message-ID: <563B0F53.8010803@orange.com>
Date: Thu, 05 Nov 2015 09:12:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <E70EB200-09AE-464C-A0B2-38F480489F16@ericsson.com>
Content-Type: text/plain; charset="windows-1251"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/BthUqfGV1WcICUYWZgtLXhWCGyc>
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] Regarding draft-ppsenak-ospf-te-link-attr-reuse-00
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, 05 Nov 2015 08:12:11 -0000

Hi Jeff,

Following the WG session yesterday, I'm glad to (lately) join the 
thread. Please, see my comments below as [JM].


Oct. 26, 2015 - jeff.tantsura@ericsson.com:
> Hi,
> No hats
>
> I'm familiar with at least 2 implementations which have this issue, this draft solves real problem.
>
> Regards,
> Jeff

[JM] Then you may consider patching them to do parameter duplication on 
the receiver side, not on the wire and/or the emitter configuration...
Do you imagine operational people tearing hair out while trying to guess 
if they need to configure SRLGs in here, there or both? All the more as 
two places would multiply configuration discrepancies.

In the I-D, the beginning and the end of section 3.1 provide a good summary:
- "One approach for advertising link attributes is to _continue_ to use 
TE Opaque LSA"
- advantages: "no additional standardization requirement", "link 
attributes are only advertised once".
I cannot agree more on these.

In other words, some new use cases, not matching the original one, do 
not justify to allocate new code points to the same information (cf. 
IS-IS non-issue). In the IETF, uses cases aim at scoping protocol work, 
they aren't made to limit protocol future uses.

Cheers,

Julien