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

[[e-mail]]

+1

Support adoption of this work. Technical detail looks good.

Suggestion: This doc reads a bit like a suspense novel where you only understand in the 4th act why
this should be a standard and what its scope is. Would suggest to make abstract/intro more
crisp wrt the salient points:

1. There is ongoing work and DEMAND to build non-TE apps using the same attributes as invented by TE
2. Multiple applications will need the same attributes but with different values.
3. This doc reviews attributes, use-cases & options and STANDARDIZES that multi-application encoding
4. Standardized processing for these attributes outside TE is subject to ongoing/future work.

Would also suggest considering putting "Multi-Application (encoding or reuse)" into the title

Cheers
      Toerless

On 7/7/17, 10:22, "OSPF on behalf of Acee Lindem (acee)" <[e-mail] on behalf of [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
    


_______________________________________________
OSPF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ospf