Hi Ron, Please kindly enlighten me on your line of thinking ...
Let's consider your list: Total physical bandwidth Number of LAG elements Bandwidth of smallest lag member Latency Then as a method of distributing them you choose your option 3 which reads: "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." Question: How can you configure any of the metrics you enumerated "in a few central places" irrespective on how we encode it in IGP ? Isn't each of those properties local to each node which needs to be flooded via a domain from each node ? Thx, R. On Tue, Aug 17, 2021 at 8:20 PM Ron Bonica <rbonica= 40juniper....@dmarc.ietf.org> wrote: > 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: > > > > 1. Configure this information on each link and advertise link > attributes with ASLA > 2. Configure this information on each node that runs the application > 3. 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
