Chris, draft-hegde-ospf-advertising-te-protocols has following limitations:
1. only solves the problem of RSVP and Segment Routing TE. It does not address any other non-TE applications - e.g. LFA, SPF based on the delay or bandwidth, or anything that may come in the future.
2. it took the approach of "indicating the protocols enabled on the link". While this may be good for RSVP, it does not work for other applications. For example the fact that the LFA is enabled on a remote link is orthogonal to the fact whether the SRLG value on such link is going to be used by LFA calculation on other nodes in a network.
3. does not support per application values. You questioned the use case of SRLG. Well, we have a real use case, where operator runs RSVP TE and SRTE in parallel and wants to know bandwidth available for each.
You mentioned problems with advertising same attribute in multiple places. Well, we already do this today with metric, we advertise IGP metric in Router LSA and TE metric in TE Opaque LSA. There is no problem here, because each application knows where to look. RSVP TE has its own container and any data in this container are clearly RSVP TE specific. Rest of the applications should never look at these. RFC7684 defines the container for generic link attributes and that is what we should use for any non-RSVP applications.
When original RSVP TE extensions for IGPs were done, nobody was thinking about other applications using these link attributes. Today we clearly have use cases and now we need to address the lack of support for other applications.
The authors of the draft-ppsenak-ospf-te-link-attr-reuse draft strongly believe that as we make the link attributes available for other applications, it is the right time to add the support for per application values, so we do not need to come back and address that problem again in the future. The proposed encoding in the draft avoids any replication if there is a single value of the attribute used by all/several applications, while allowing the per application values to be advertised if needed.
In summary, draft-hegde-ospf-advertising-te-protocols only address the subset of the problems that draft-ppsenak-ospf-te-link-attr-reuse is solving.
thanks, Peter On 01/11/16 17:04 , Chris Bowers wrote:
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 .
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
