Re: [OSPF] WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse

"Acee Lindem (acee)" <> Fri, 07 July 2017 17:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15B1113178B for <>; Fri, 7 Jul 2017 10:22:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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, 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JoPxeqksSaB3 for <>; Fri, 7 Jul 2017 10:22:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B01C131762 for <>; Fri, 7 Jul 2017 10:22:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4800; q=dns/txt; s=iport; t=1499448144; x=1500657744; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=AwWN8G5UqVWFyX383rCZP0dM59Fsl4Rvp8dxJuX56F4=; b=PlO/M1qrlI4zj/lu/VSDoOuU3idI8x0GlqoUEX1OdaaiKJgqYPv2+OWT gdEPP15GtZcf9XuJfI/QlOIzWUy1HeNfvdWbb7L8X99plxy+Ocb4ByEHb olhZNmt6s58Sosnpl7EMVSe3v9ggLlZx5+HLKR+sE8D5FIN9V9mxSsEUI 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.40,323,1496102400"; d="scan'208";a="451811676"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jul 2017 17:22:04 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v67HM4r6029885 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <>; Fri, 7 Jul 2017 17:22:04 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 7 Jul 2017 13:22:03 -0400
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Fri, 7 Jul 2017 13:22:03 -0400
From: "Acee Lindem (acee)" <>
To: "Acee Lindem (acee)" <>, "Abhay Roy (akr)" <>, "" <>
Thread-Topic: [OSPF] WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse
Thread-Index: AQHS9qScRSc0kkj1oUG/hY/7Y6Sh6aJIncwA
Date: Fri, 07 Jul 2017 17:22:03 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OSPF] WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse
X-Mailman-Version: 2.1.22
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: Fri, 07 Jul 2017 17:22:26 -0000

                OSPF Evolution and the role of

The document draft-ppsenak-ospf-te-link-attr-reuse-05.txt not-only
provides flexible and compact mechanisms and encodings for advertising
link attributes for single or multiple applications. It is also part of
the wider goal of transforming OSPF to a TLV-based protocol that is every
bit as extendable as the other IGPs while affording the distinct advantage
of optimally partitioning the advertised information into multiple LSAs of
different types. 

This draft represents the last piece of our vision to achieve this
outcome. For OSPFv2, we have the base LSAs that cannot be extended in a
backward compatible fashion. Additionally, we have RFC 7770 (OSPF Router
Information Advertisement) and RFC 7684 (OSPF Prefix/Link Attributes). The
former has been extended to support distribution of non-OSPF information
in addition to OSPF Router-level protocol information. The extended OSPF
Prefix/Link LSAs are being used to support segment routing and other
technologies. They are now part of the OSPF base and will be advertised in
many OSPF domains. The major implementations have the capability to
correlate the base LSAs and the OSPF Prefix/Link LSAs for segment routing.
This correlation requires handling lots of chicken and egg complexities
that have all been overcome.

It has been suggested that since the OSPF TE LSAs (RFC 3630) contain some
generally useful link attributes, this be the only means by which this
information is advertised in OSPF routing domains. This will be both
unwieldy and inefficient due to the advertisement, processing, and storage
of the TE LSAs in networks not utilizing RSVP-based TE.  There is also the
added complexity with this approach as you have not only the chicken and
the egg, but the chicken, egg, and the rooster to correlate.

For OSPFv3 and OSPFv3 Extended LSAs
(draft-ietf-ospf-ospfv3-lsa-extend-14.txt), we have made the difficult
choice to extend the base RFC 5340 LSAs (OSPF for IPv6) in a
non-compatible fashion. After an initial delay, we have implementations of
the OSPFv3 Extended LSAs draft and will soon be advancing it. With the
OSPFv3 extended LSAs, we are finally at the point where all the
information (other than RSVP TE information) for a given prefix or link is
advertised in a single LSA rather than multiple LSAs. Would those who
argue for making OSPFv2 TE LSAs generally applicable also want to require
the advertisement of RFC 5329 (OSPFv3 Traffic Engineering) LSAs?  If so,
we would miss a tremendous opportunity.


On 7/6/17, 6:10 PM, "OSPF on behalf of Acee Lindem (acee)"
< on behalf of> wrote:

>Support as co-author. More to come…
>On 7/3/17, 2:37 PM, "OSPF on behalf of Abhay Roy (akr)"
>< on behalf of> wrote:
>>We would like to kick-off a poll for WG adoption of the following
>>document (per Authors request):
>>Please let us know if you support or have concerns with OSPF WG adopting
>>this work.
>>OSPF mailing list
>OSPF mailing list