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

["Naiming Shen (naiming)" <[e-mail]>]

Support the adoption.

- Naiming

> On Jul 7, 2017, at 10:22 AM, Acee Lindem (acee) <[e-mail]> 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)"
> <[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
> 
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf