[OSPF] OSPF TE Attribute Binding to Applications Dynamicity

"Acee Lindem (acee)" <acee@cisco.com> Tue, 16 May 2017 21:21 UTC

Return-Path: <acee@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8A4D412EBDE for <ospf@ietfa.amsl.com>; Tue, 16 May 2017 14:21:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3ZtZVDCvI29c for <ospf@ietfa.amsl.com>; Tue, 16 May 2017 14:21:30 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EBF212EC7A for <ospf@ietf.org>; Tue, 16 May 2017 14:16:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6161; q=dns/txt; s=iport; t=1494969414; x=1496179014; h=from:to:cc:subject:date:message-id:mime-version; bh=HIz82bWhbXJesmypevE3eY/m9WZZPRGysdH1b7Lw0dw=; b=XnKJABfogLlMyiJtZwGGTBAuyF4b1fVWS5Vx8hAVEAdR6p5oA5ZBg+DU BwMLNekzjqJstQWyd8mjyxSOh6yD3MmBjcBUri+tb51DJVRvNey1zSqJ7 hRBfmMMpUHZ5mN5yFi1FiCY8Diq9a8/kCPRMUHljnD2zsewroQ6sPecVH A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.38,350,1491264000"; d="scan'208,217";a="244349163"
Received: from rcdn-core-12.cisco.com ([]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 May 2017 21:16:53 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com []) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v4GLGrQr032656 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 16 May 2017 21:16:53 GMT
Received: from xch-rtp-015.cisco.com ( by XCH-RTP-011.cisco.com ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 16 May 2017 17:16:52 -0400
Received: from xch-rtp-015.cisco.com ([]) by XCH-RTP-015.cisco.com ([]) with mapi id 15.00.1210.000; Tue, 16 May 2017 17:16:52 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Stephane Litkowski <stephane.litkowski@orange.com>
CC: OSPF WG List <ospf@ietf.org>, OSPF ADs <ospf-ads@tools.ietf.org>
Thread-Topic: OSPF TE Attribute Binding to Applications Dynamicity
Thread-Index: AQHSzom9Asque1ZSoUCRhWfw3PlDuw==
Date: Tue, 16 May 2017 21:16:52 +0000
Message-ID: <D540E47E.AF214%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D540E47EAF214aceeciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/shNVLYagCQCuGpSjQGTg5ErT00k>
Subject: [OSPF] OSPF TE Attribute Binding to Applications Dynamicity
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 16 May 2017 21:21:31 -0000

At the OSPF WG meeting in Chicago, Stephane Litkowski expressed the desire to have a more dynamic mechanism for binding attributes to applications. I’ve thought about this for some time and see the following potential use cases.

    1. Usage for an application prior to early IANA allocation of a bit position for that application.
    2. Usage for user applications that will never be standardized but still require link (and potentially prefix) attributes.

Are there any others?

An application tagging mechanism was suggested for this purpose. However, I still believe the bit-mask encoding can satisfy these use cases.

The first requirement could be satisfied by allocating some number of experimental bit positions in the initial bit mask specification. These could be used for experimental applications prior to IANA early allocation. Similarly, the second requirement could be satisfied by allocating some number of user-application bit positions in the initial bit-mask allocation. I really don’t see significant advantage of a tag over a bit position as, no matter what mechanism is used, all the OSPF routers in the routing domain will need to agree on what bit/tag corresponds to what application. For the first use case, this would be decided among the implementors supporting the experimental application while in the second use case, the application binding would likely need to be configured.

The only argument I could see for a application tag would be that you need too many bits of either type (experimental or user applications). In this case, we could still use a bit mask in the OSPF Prefix/Link Attribute LSA and advertise the application identifier (i.e., tag) to bit position mappings in the OSPF Router Information LSAs. However, I don’t think this level of indirection is necessary.