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

Peter Psenak <ppsenak@cisco.com> Thu, 05 November 2015 08:40 UTC

Return-Path: <ppsenak@cisco.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 DB3C11A8A63 for <ospf@ietfa.amsl.com>; Thu, 5 Nov 2015 00:40:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 EE2hpxZf7jXo for <ospf@ietfa.amsl.com>; Thu, 5 Nov 2015 00:40:12 -0800 (PST)
Received: from bgl-iport-4.cisco.com (bgl-iport-4.cisco.com [72.163.197.28]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72E651A8A56 for <ospf@ietf.org>; Thu, 5 Nov 2015 00:40:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2330; q=dns/txt; s=iport; t=1446712811; x=1447922411; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=qq3nN22HzjstkQYNFRYq9l8lVeBwLFKT2W+Su33NucI=; b=TGVhd7U8Qb6JbHS0MMOcIuXh/wY3BNNP907dL9f99v6ya2zK+oJM91aR x64kWBY9p/0kTfqZSgPo7fuIMX54Cy6F2NYXNFhqLV2WbTc6tU/7f9UnZ wzV6u1B+8AsKY5KMhzlZ/nj8/wXmgou6uRL9G5L4mtoJ9i9EwpctEN2PO w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DOAQD4FDtW/xjFo0hehA5vvXMBDYFeFwqFcQKBbBQBAQEBAQEBgQqENQEBAQMBAQEBNTYLEAsYCSUPAhYwBgEMAQUCAQGIIggNwXUBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZUhH6ENYUEAQSHRop5hAmNI4FahD+DAiOTBB8BAUKEBT00g1aBSQEBAQ
X-IronPort-AV: E=Sophos;i="5.20,246,1444694400"; d="scan'208";a="25861698"
Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-4.cisco.com with ESMTP; 05 Nov 2015 08:40:03 +0000
Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by bgl-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tA58e0Ad004805; Thu, 5 Nov 2015 08:40:02 GMT
Message-ID: <563B15E0.90101@cisco.com>
Date: Thu, 05 Nov 2015 09:40:00 +0100
From: Peter Psenak <ppsenak@cisco.com>
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 <julien.meuric@orange.com>, 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> <563B0F53.8010803@orange.com>
In-Reply-To: <563B0F53.8010803@orange.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/DNDcryoETTsKHPgIpbXOzw5fpZY>
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:40:14 -0000

Hi Julien,

On 11/5/15 09:12 , Julien Meuric wrote:
> 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.

above is incorrect.
Nobody is proposing to configure things like SRLG on multiple places.
You configure it on a single place, as you do today. If IGP is enabled 
for global SRLG protection, IGP pulls the SRLGs and advertise them in 
the Extended Prefix LSA. If TE is enabled and want to use SRLGs, it 
pulls it from the same place, form the TE Opaque LSA and asks IGP to 
flood it.

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

have you read the "disadvantage" section as well?

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

I;m afraid you are missing the point.
TE Opaquer LSA are defined as LSAs that advertise TE topology that is 
disjoint from the IGP topology (RFC3630). We can NOT make the link part 
of the TE topology, just because we want to advertise SRLG or some other 
attribute that is used by IGP for LFA - that would break the RFC3630.

thanks,
Peter

>
> Cheers,
>
> Julien
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
> .
>