Re: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse

["Acee Lindem (acee)" <[e-mail]>]

Speaking as a WG member:

I agree with all the points Peter has made.  Furthermore, I’d like to
emphasis the fact that we standardized the OSPF Prefix/Link Attribute (RFC
7684) as
the generic attribute container. When applications such as segment routing
are deployed, we don’t want to also have to advertise OSPF TE LSAs in
addition to the OSPF Prefix/Link Attribute LSAs. In addition to the
advertisement overhead, having to track and correlate these multiple LSAs
will result in additional implementation complexity. Once we get
draft-ietf-ospf-ospfv3-lsa-extend implementations, we’ll have all the
non-TE link attributes in the E-Router-LSA. This is where we want to end
up 

Thanks,
Acee 

On 11/3/16, 6:53 AM, "Peter Psenak (ppsenak)" <[e-mail]> wrote:

>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:[e-mail]] On Behalf Of Abhay Roy
>> Sent: Wednesday, October 26, 2016 12:28 AM
>> To: [e-mail]; [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ospf
>>
>> _______________________________________________
>> OSPF mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ospf
>> .
>>
>