OSPF WG, I do not support adoption of draft-ppsenak-ospf-te-link-attr-reuse-03 as a WG document.
The draft-ppsenak-ospf-te-link-attr-reuse has highlighted a real issue that needs to be addressed. OSPF does not have a standardized mechanism to determine if RSVP is enable on a link. Implementations have instead relied on the presence of the TE Opaque LSA with a given Link TLV to infer that RSVP is enabled on a link. This presents a problem when one wants to use TE attributes carried in the Link TLV of the TE Opaque LSA in an environment with both RSVP and non-RSVP applications. There is currently no standardized way for a TE attribute to be advertised on a link for use by a non-RSVP application without causing existing implementations to infer that RSVP is enabled on the link. The solution proposed by draft-ppsenak-ospf-te-link-attr-reuse is to allow the TE attributes originally defined to be carried in the Link TLV of the TE Opaque LSA to be advertised in the Extended Link TLV of the Extended Link Opaque LSA. The current draft proposes allowing the advertisement of the following attributes in either the Link TLV of TE Opaque LSA or the Extended Link TLV of the Extended Link Opaque LSA. Remote interface IP address Link Local/Remote Identifiers Shared Risk Link Group Unidirectional Link Delay Min/Max Unidirectional Link Delay Unidirectional Delay Variation Unidirectional Link Loss Unidirectional Residual Bandwidth Unidirectional Available Bandwidth Unidirectional Utilized Bandwidth There has already been a great deal of discussion on the OSPF list about the potential problems caused by moving or replicating the advertisement of existing TE attributes in different containers. It can create problems for both implementers and network operators when the same attribute can be advertised in multiple places. Implementers need to apply some logic to figure out where to advertise and where to find the value of the attribute that should be used in a given set of circumstances. Different implementers may apply subtly different logic. Network operators will have to test the different implementations against each other to make sure that the logic applied produces the desired result in their network. In many cases, they will also have to test these different new implementations against existing software that only sends and receives TE attributes in the TE Opaque LSA. A few months ago we published draft-hegde-isis-advertising-te-protocols which addresses the same basic issue in ISIS. The same approach also works for OSPF, so we recently published draft-hegde-ospf-advertising-te-protocols. draft-hegde-ospf-advertising-te-protocols-00 proposes a straightforward solution to the problem described above. It defines a new TE-protocol sub-TLV to be carried in the Link TLV of the TE Opaque LSA to indicate which TE protocols are enabled on a link. Currently it defines values for RSVP and SR. The draft also provides clear backward compatibility mechanisms for routers that have not yet been upgraded to software that understands this new sub-TLV. The approach in draft-hegde-ospf-advertising-te-protocols-00 is straightforward. It leaves the existing TE attributes in the TE Opaque LSA, allowing implementations to continue to advertise and find traffic engineering the information in the TE Opaque LSA. The latest version of draft-ppsenak-ospf-te-link-attr-reuse (the -03 version) added an Application Bit Mask. The idea of the Application Bit Mask is to allow different values of TE attributes to be defined for different applications. It is not clear to me that this part of the draft addresses an existing problem. The text gives one example use case involving having different sets of SRLGs for SR and for LFA. If network operators do in fact have a need for different sets of SRLGs, then we should figure out what is needed and propose a solution based on what is actually needed. This draft would also provide encodings to advertise different Link Delay and Link Loss values for a given link. I can't think of a potential use case for that, since Link Delay and Link Loss are measured values. Overall, this draft has been useful in highlighting the existing lack of a standardized mechanism to indicate whether or not RSVP is enabled on a link. However, I don't think that the solution it proposes is a good starting point for the WG to address this issue. Chris -----Original Message----- From: OSPF [mailto:[email protected]] On Behalf Of Abhay Roy Sent: Wednesday, October 26, 2016 12:28 AM To: [email protected]; [email protected] Subject: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse Dear WG, Authors of draft-ppsenak-ospf-te-link-attr-reuse would like to poll the WG for adoption of this document as a WG Draft. Please send your opinions / concerns. This begins the two week WG adoption poll which will conclude on Nov 9th 2016. Authors, we need your explicit response on this thread to capture your answer on if you are aware of any IPR related to this draft. 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
