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

Jeff Tantsura <> Fri, 07 July 2017 18:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9218413162F for <>; Fri, 7 Jul 2017 11:27:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pirJG_kxQJ9f for <>; Fri, 7 Jul 2017 11:27:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0F98A1275AB for <>; Fri, 7 Jul 2017 11:27:03 -0700 (PDT)
Received: by with SMTP id q85so5557979pfq.2 for <>; Fri, 07 Jul 2017 11:27:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=buKKUeJ8kyTxLZPxtZA82uYcKLdb2fy36UoXG0VuoYM=; b=c3YfX/omyi8u24wu5JhplwhND56BoEZfoBe3GP6qYdZHtzPwDNoTHwTqUs+T7RpWuv RhCXuIjwOnaEY2+7Du6mSjAJkDVGEZbo+P+VNwh+CWw6b6pM//rKBKLZaYH/fnxOYo0J v5/cExgjMwKn4pWRtS1bylce3Lgf0BJVYPkfigXMjUAVdESKIwbaVX0yEL5icusa723B kGgTrduzjjwwAzMS3kba+rVDNjsSZ6nOXC8ekvVTy3Eib07ccNpRe/wCUo6rJI1bb2uy /3fVID/BBY9tfi+mH1VObVsaRGDEiou6TCPfDnnVC5+U4szsW+StsB0roxXt7hnOnEba KhAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=buKKUeJ8kyTxLZPxtZA82uYcKLdb2fy36UoXG0VuoYM=; b=SXx0MK5q84lv2VFKEqN0BJtpNsxdOwdLeoFq//w7qWsNEbPqR4tVjOSDuKPe/jTbnr Mnla7wshWmJyuvXkkAMftoCL8OBCtP6KnMTo6UbNUNxERLXILu1EUiC9X8We3u53I1fj 2CJE9YKv2taZ0tXZ48G1Z8DMTqRfTCae65hZC22ucrYrR5woGb0UdqDjftDEsSoOcThQ kZMduIaaNBkN4xbd4saGh0CecLz4iHKUHOTgSV6itRvbgnsPjVAdMH8FSHZhrYI8YZUn JRFOdfc9rw0XLFRq7SjjkvcEXOkTTWKChH1Nk6ysroJTJImKgxnezIKDQlSTMH46bRSr 8EUQ==
X-Gm-Message-State: AIVw11362IQMjajSA22IPHXx5RagMawt4o8btQ3e5/i903FWLoho4awS ecPa0GVvttsbwqmW
X-Received: by with SMTP id l3mr4527377pld.232.1499452022485; Fri, 07 Jul 2017 11:27:02 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id r27sm8061423pfe.0.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 11:27:01 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/f.21.0.170409
Date: Fri, 07 Jul 2017 11:26:59 -0700
From: Jeff Tantsura <>
To: "Acee Lindem (acee)" <>, "Abhay Roy (akr)" <>, "" <>
Message-ID: <>
Thread-Topic: [OSPF] WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse
References: <> <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
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 18:27:06 -0000

+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