we are going in rounds, +1 Les! Cheers, Jeff
>> On Aug 18, 2021, at 1:20 PM, Les Ginsberg (ginsberg) >> <ginsberg=40cisco....@dmarc.ietf.org> wrote: >> >> Ron - >> >> Indeed – it is long past the time when we should be focusing on the “big >> picture”. >> I think Acee has stated it as succinctly as anyone – let me repeat for >> emphasis: >> >> “The LSR WG developed ASLAs to cover usage of the link attributes (including >> metrics) for different applications and mitigate all the vagaries of the >> original TE link attribute specifications. ASLAs are implemented and >> deployed. I believe it would be a mistake to bifurcate the IGP standards >> with yet another way of encoding link attributes for different applications.” >> >> ASLA is an architecture – one designed to assure that we can explicitly >> identify the set of applications using any link attribute . It is designed >> to be extensible both to new applications and to new attributes. It was long >> debated in the WG and underwent extensive review and is now standardized in >> RFCs 8919, 8920. It has been implemented and deployed and forms the basis of >> interoperable implementations. >> >> Now you (and others) decide to invent a new attribute. The attribute >> certainly can be advertised using ASLA, but instead of acknowledging the >> existence of the ASLA architecture and defining the new attribute to use >> ASLA, you decide that maybe if we advertise this attribute in some new way >> there might be some modest advantages. This ignores the consequences of >> having to implement attribute specific encoding rules in order to map >> attributes to applications. These consequences include greater code >> complexity and higher probability of interoperability issues. >> >> And, based on your list of attributes below, what have we to look forward >> to? More attribute specific encoding rules leading to even greater code >> complexity and greater chance of interoperability problems it would seem. >> >> Look, you haven’t convinced me that your alternative proposals are “better”. >> But even if they were, it would require a much greater benefit than you are >> claiming to justify discarding the architecture that is designed to fully >> address the association of link attributes and the applications which use >> them. >> >> I don’t expect to convince you – and you have not convinced me – and we >> probably never will agree. But since it is clear that ASLA does work for all >> the cases that have been mentioned in this and related threads, I think this >> discussion is a waste of WG time. >> >> It is time to close this discussion. >> >> Les >> >> >> From: Lsr <lsr-boun...@ietf.org> On Behalf Of Ron Bonica >> Sent: Tuesday, August 17, 2021 11:21 AM >> To: Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org>; lsr@ietf.org >> Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW >> Constraints >> >> Acee, >> >> So, let us discuss whether there is a good reason for >> draft-ietf-lsr-flex-algo-con to specify ASLA ! >> >> Link attributes are different from application configuration information. >> Link attributes are properties of a link. They are independent of the >> applications that use them. The following are examples: >> >> Total physical bandwidth >> Number of LAG elements >> Bandwidth of smallest lag member >> Latency >> >> Link attributes do not benefit from ASLA encoding because they are not >> application specific. >> >> Application configuration information constrains the behavior of an >> application. It can apply to: >> >> The application and a link >> The application only >> >> Bandwidth reservation applies to an application and a link. For example, a >> link may advertise that it has: >> >> X Gbps available for RSVP-TE reservations >> Y Gbps available for SR Policy reservations >> Z Gbps available for TI-LFA reservations >> >> This class of configuration information clearly benefits from ASLA encoding, >> because it is applicable to both the application and the link. >> >> Some applications (e.g., Flexalgo) can be configured to use a variety of >> link attributes in SPF calculation. No matter how they acquire this >> configuration information, it MUST be the same at each node. Otherwise, >> routing loops may result. Configuration options are: >> >> Configure this information on each link and advertise link attributes with >> ASLA >> Configure this information on each node that runs the application >> Configure this information in a few central places and advertise it to all >> other nodes. The advertisement is not associated with a link. Flexalgo uses >> the FAD in this manner. >> >> Neither Option 1 nor Option 2 is very appealing, because it requires >> configuration on each node. Option 3 is better because: >> >> It requires configuration on only a few nodes >> It maintains separation between link attributes and application >> configuration information >> It can support applications like Flexalgo, where each algorithm may use >> different link attributes to calculate the shortest path >> >> >> Ron >> >> >> >> >> Juniper Business Use Only >> From: Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org> >> Sent: Friday, August 13, 2021 10:22 AM >> To: Ron Bonica <rbon...@juniper.net>; lsr@ietf.org >> Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW >> Constraints >> >> [External Email. Be cautious of content] >> >> Speaking as a WG member: >> >> Hi Ron, >> My rationale is #1. The LSR WG developed ASLAs to cover usage of the link >> attributes (including metrics) for different applications and mitigate all >> the vagaries of the original TE link attribute specifications. ASLAs are >> implemented and deployed. I believe it would be a mistake to bifurcate the >> IGP standards with yet another way of encoding link attributes for different >> applications. >> Thanks, >> Acee >> >> From: Lsr <lsr-boun...@ietf.org> on behalf of Ron Bonica >> <rbonica=40juniper....@dmarc.ietf.org> >> Date: Thursday, August 12, 2021 at 3:46 PM >> To: "Acee Lindem (acee)" <acee=40cisco....@dmarc.ietf.org>, "lsr@ietf.org" >> <lsr@ietf.org> >> Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW >> Constraints >> >> Acee, >> >> Please help me to parse your message. It is clear that you want >> draft-ietf-lsr-flex-algo-bw-con to specify ASLA’s. However, your rationale >> is not so clear. >> >> It is not because RFC 8919 mandates ASLA. In fact, we agree that it would be >> strange for an RFC to include a mandate that precludes future proposals. >> >> Are any of the following your rationale: >> >> 1) Because there is a good technical reason for >> draft-ietf-lsr-flex-algo-bw-con to specify ASLA >> 2) Because it is possible, but not necessary, for >> draft-ietf-lsr-flex-algo-bw-con to specify ASLA >> 3) Because it was the unstated intention of RFC 8919 to include a >> mandate that precludes future proposals (although we agree that this would >> be strange). >> >> For the purposes of full disclosure, I think discussion regarding the first >> rationale would be fruitful. However, I don’t think very much of the second >> or third rationale. >> >> >> Ron >> >> >> >> >> Juniper Business Use Only >> From: Lsr <lsr-boun...@ietf.org> On Behalf Of Acee Lindem (acee) >> Sent: Tuesday, August 10, 2021 4:43 PM >> To: lsr@ietf.org >> Subject: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints >> >> [External Email. Be cautious of content] >> >> Speaking as a WG Member: >> >> In reviewing RFC 8919 and RFC 8920, it is clear that the ASLA mechanism >> was to be used for new link attributes and applications. While the documents >> do not mandate that there never could be a new way to advertise link >> attributes, this was clearly the intent. Indeed, it would be strange for an >> RFC to include a mandate that precluded future proposals. The advertisement >> enablement and deployment sections of these documents specifically cover >> future attributes and applications. >> >> Given that we have ASLAs as building blocks, I don’t really see a reason >> to introduce the generic metric. The proponents say it isn’t an alternative >> to ASLAs but their examples cite different applications using different >> metric types (i.e., application-specific metrics). Also, given that ASLA are >> used by the base Flex Algo draft, it would be inconsistent to diverge for >> Flex Algo BW constraints. >> >> Consequently, I would request that draft-ietf-lsr-flex-algo-bw-con-01 >> revert to using ASLAs. Based on the LSR Email discussion prior to IETF 111, >> this was definitely the consensus. >> >> Thanks, >> Acee >> >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
