There is general agreement that protocol extensions are required to address new requirements related to the use of link attributes historically associated only with RSVP-TE. That is why we have two drafts in OSPF on the subject:
https://datatracker.ietf.org/doc/draft-ppsenak-ospf-te-link-attr-reuse/ and https://datatracker.ietf.org/doc/draft-hegde-ospf-advertising-te-protocols/ In the recent WG meeting there was a rather "exciting" debate about the merits/demerits of the two proposals- but I think if we filter out the emotions and focus on the things we know to be true then it should be straightforward to decide which of the approaches should be pursued. Evolution of use cases for link attributes can be expected to continue - so any discussion of existing use cases is limited to requirements which are known at the time of this writing. However, in order to determine the functionality required beyond what already exists in the protocol, it is only necessary to discuss a single use case. rfc7855<https://www.rfc-editor.org/rfc/rfc7855.txt> discusses use cases/requirements for SR. Included among these use cases is SR-TE. If both RSVP-TE and SR-TE are deployed in a network, links can be used by one or both of these applications. As there is no requirement for the topology supported for SR-TE to be congruent to the topology supported for RSVP-TE there is a clear requirement to indicate independently which applications are associated with a given link. If both RSVP-TE and SR-TE are enabled on the same link it is also possible that an attribute such as Maximum Bandwidth to be utilized by SR-TE may be different than/disjoint from the Maximum Bandwidth to be utilized by RSVP-TE. This leads to two clear requirements: 1)Support for indicating which applications are using the link attribute advertisements on a link 2)Support for advertising application specific values for the same attribute on a link Only draft-ppsenak-ospf-te-link-attr-reuse meets both of these requirements. draft-hegde-ospf-advertising-te-protocols only supports the first requirement. Another topic debated at the recent WG meeting was the issue of backwards compatibility. It is a given that routers supporting the protocol extensions will have to co-exist with legacy routers, so backwards compatibility is important. Here again there is a clear advantage for draft-ppsenak-ospf-te-link-attr-reuse as it fully supports backwards compatibility (i.e. no impact to legacy routers) by advertising duplicate advertisements when necessary. draft-hegde-ospf-advertising-te-protocols cannot support backwards compatibility in cases where SR-TE is enabled on some links and RSVP-TE is enabled on other links as it uses legacy advertisements of the attribute in both cases. draft-hegde-ospf-advertising-te-protocols does offer a partial deployment strategy - but this requires introducing new configuration (affinity) on legacy routers. There was also discussion that writing a use case/requirements document would be desirable - to which I agree. However, the major benefit of a use case document will be to define which of the many link attributes are candidates for per application advertisements. This will not discover the requirement for application specific advertisements - we already have at least one such case - though it will potentially discover additional cases. The framework required for the protocol extensions will not change as a result of the writing of the use case document - so the best way forward is to work on the use case document and the protocol extensions in parallel. I therefore strongly believe the WG should adopt draft-ppsenak-ospf-te-link-attr-reuse without further delay. WG adoption call was already started and has to date received support from multiple people (NOT counting the co-authors). The only dissenting opinions have come from the authors of draft-hegde-ospf-advertising-te-protocols. I also believe that the suggested use case document should go forward as well to help define the use cases to which the new protocol extensions apply - but we can and should do this work in parallel with the protocol extensions. I have attached a slide summarizing the capabilities of the two competing drafts as an aid to understanding the differences between the two proposals. Les
te_app.pptx
Description: te_app.pptx
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
