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

["Acee Lindem (acee)" <[e-mail]>]

                OSPF Evolution and the role of
draft-ppsenak-ospf-te-link-attr-reuse

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.


Thanks,
Acee

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

>Support as co-author. More to come…
>Acee 
>
>On 7/3/17, 2:37 PM, "OSPF on behalf of Abhay Roy (akr)"
><[e-mail] on behalf of [e-mail]> wrote:
>
>>We would like to kick-off a poll for WG adoption of the following
>>document (per Authors request):
>>
>>https://datatracker.ietf.org/doc/draft-ppsenak-ospf-te-link-attr-reuse
>>
>>Please let us know if you support or have concerns with OSPF WG adopting
>>this work.
>>
>>Regards,
>>-Abhay
>>
>>_______________________________________________
>>OSPF mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/ospf
>
>_______________________________________________
>OSPF mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ospf