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

Huaimo Chen <> Mon, 10 July 2017 01:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C388A12955F for <>; Sun, 9 Jul 2017 18:44:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XDgWdEUc9huS for <>; Sun, 9 Jul 2017 18:44:39 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7535F1289C3 for <>; Sun, 9 Jul 2017 18:44:38 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DKB10775; Mon, 10 Jul 2017 01:44:36 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 10 Jul 2017 02:44:35 +0100
Received: from ([]) by ([]) with mapi id 14.03.0301.000; Sun, 9 Jul 2017 18:44:32 -0700
From: Huaimo Chen <>
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/7Y6Sh6aJIncwAgACHgYCAADL9gIAC9Mww
Date: Mon, 10 Jul 2017 01:44:31 +0000
Message-ID: <>
References: <> <> <> <> <594D005A3CB0724DB547CF3E9A9E810B4F58B2@dfweml501-mbx>
In-Reply-To: <594D005A3CB0724DB547CF3E9A9E810B4F58B2@dfweml501-mbx>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5962DC04.00B9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: bd648d4710d09166ca9d98c9e25f90cb
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: Mon, 10 Jul 2017 01:44:42 -0000


Best Regards,
-----Original Message-----
From: OSPF [] On Behalf Of Jeff Tantsura
Sent: Friday, July 07, 2017 11:27 AM
To: Acee Lindem (acee) <>; Abhay Roy (akr) <>;
Subject: Re: [OSPF] WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse

+10 to Acee’s comments
OSPF community would greatly benefit from the draft being adopted and implemented (stated as co-author)

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

                    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
    OSPF mailing list

OSPF mailing list
OSPF mailing list