Hi OSPF chairs, Peter, Chris, To add my opinion to this thread. The issue of having multiple places in which one might advertise TE related information is one that I think there can be multiple takes on. Particularly, whilst I can see that there is an argument that duplication of such attributes might result in ambiguity in which is used, we must also consider what happens when the TE information for one protocol does not apply for others that are running within the same network. This is particularly important during the period where there is coexistence of multiple protocols on the device. In order to explicitly allow the operator to choose how resources might be partitioned on the network, then to me it seems like we need more than simply "is this link eligible to carry TE paths that are signalled via protocol X".
As well as resource partitioning (e.g., subsets of bandwidth being available per application for example), there appear to me to be potential use cases where the administrative groups across the protocols may differ, when a subset of links are eligible for a particular protocol's paths and not another's. Not being able to do this scoping makes the difficult problem of coexistence even more difficult, so having the flexibility to tag particular attributes for links based on application seems (generically) to be more useful than the simple ability of partitioning the network link-by-link that is proposed in draft-hegde-ospf-advertising-t e-protocols-00. Operationally - yes - if one specifies metrics in multiple places this might have some ambiguity, however, we have many years of experience of such a scenario - where TE metric might make RSVP-TE act differently in terms of path selection than the base IGP metric. Those networks that do not derive benefit from the additional attributes will simply not set them, or make their value exactly mirrored between the different protocols that they run. Those that do have benefit will have the flexibility to utilise them, but have to deal with the additional operational overhead that comes with it. I would prefer that we adopt the more flexible approach (this draft), and then work out the implementation and operational complexities that might be introduced, than to adopt an approach which leaves us with few extensibility options going forward. Cheers, r. On Thu, Nov 3, 2016 at 10:48 AM Jeff Tantsura <[email protected]> wrote: > Hi, > > Some history to add on top of Peter’s, IMO absolutely correct comments. > The issue is well known, we have had first discussions on the topic during > the time rLFA was going thru standardization and implementation. > Back then however there was no clean and painless way to so. > > draft-ppsenak-ospf-te-link-attr-reuse addresses exactly the issue we have > seen starting from the time TE seized to be the only application, however > now, with the new extensions (7684) we have got much better and cleaner way. > > Cheers, > Jeff > > > On 11/3/16, 6:53 AM, "Peter Psenak (ppsenak)" <[email protected]> > 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:[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 > > > > _______________________________________________ > OSPF mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ospf >
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
