Support the adoption. - Naiming
> On Jul 7, 2017, at 10:22 AM, Acee Lindem (acee) <[email protected]> wrote: > > 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)" > <[email protected] on behalf of [email protected]> wrote: > >> Support as co-author. More to come… >> Acee >> >> On 7/3/17, 2:37 PM, "OSPF on behalf of Abhay Roy (akr)" >> <[email protected] on behalf of [email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/ospf >> >> _______________________________________________ >> OSPF mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
