Ron,
On 17/08/2021 20:20, Ron Bonica 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.
generic metric of any kind is clearly a link attribute that can carry
application specific value and as such benefits from ASLA. As I
mentioned several times, we already do that for TE metric and delay that
we use as metric as well. I see absolutely no reason why generic metric
should be any different.
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
I'm not sure how the above is related to the generic-metric.
thanks,
Peter
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 <mailto:lsr-boun...@ietf.org>> on
behalf of Ron Bonica <rbonica=40juniper....@dmarc.ietf.org
<mailto:rbonica=40juniper....@dmarc.ietf.org>>
*Date: *Thursday, August 12, 2021 at 3:46 PM
*To: *"Acee Lindem (acee)" <acee=40cisco....@dmarc.ietf.org
<mailto:acee=40cisco....@dmarc.ietf.org>>, "lsr@ietf.org
<mailto:lsr@ietf.org>" <lsr@ietf.org <mailto: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 <mailto:lsr-boun...@ietf.org>> *On
Behalf Of *Acee Lindem (acee)
*Sent:* Tuesday, August 10, 2021 4:43 PM
*To:* lsr@ietf.org <mailto: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
