It is my intention too. Regards, Jeff
> On Nov 3, 2016, at 13:11, Les Ginsberg (ginsberg) <[email protected]> wrote: > > Folks – > > I am adding the IS-IS WG to this thread because the issues discussed below > apply equally to IS-IS. > > There is currently one draft in IS-IS: > https://www.ietf.org/id/draft-hegde-isis-advertising-te-protocols-01.txt > which has the same shortcomings as its OSPF counterpart: > https://www.ietf.org/id/draft-hegde-ospf-advertising-te-protocols-00.txt > > It is essential that the two IGPs provide equivalent functionality. We > therefore need a draft in IS-IS that defines functionality equivalent to that > defined in > https://www.ietf.org/id/draft-ppsenak-ospf-te-link-attr-reuse-03.txt. > > It is my intention to help write such a draft. > > Les > > > From: Rob Shakir [mailto:[email protected]] > Sent: Thursday, November 03, 2016 11:47 AM > To: Jeff Tantsura; Peter Psenak (ppsenak); Chris Bowers; [email protected] > Cc: [email protected] > Subject: Re: [OSPF] WG Adoption Poll for draft-ppsenak-ospf-te-link-attr-reuse > > 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-te-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
