*From: *Lsr <[email protected]> on behalf of Jeff Tantsura
<[email protected]>
*Date: *Thursday, August 19, 2021 at 8:14 PM
*To: *Yingzhen Qu <[email protected]>
*Cc: *"Les Ginsberg (ginsberg)" <[email protected]>,
Ron Bonica <[email protected]>, "Acee Lindem (acee)"
<[email protected]>, "[email protected]" <[email protected]>
*Subject: *[EXT]Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo
BW Constraints
we are going in rounds, +1 Les!
Cheers,
Jeff
On Aug 18, 2021, at 1:20 PM, Les Ginsberg (ginsberg)
<[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>>*On Behalf Of*Ron Bonica
*Sent:*Tuesday, August 17, 2021 11:21 AM
*To:*Acee Lindem (acee) <[email protected]
<mailto:[email protected]>>;[email protected]
<mailto:[email protected]>
*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:
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) <[email protected]
<mailto:[email protected]>>
*Sent:*Friday, August 13, 2021 10:22 AM
*To:*Ron Bonica <[email protected]
<mailto:[email protected]>>;[email protected] <mailto:[email protected]>
*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 <[email protected] <mailto:[email protected]>>
on behalf of Ron Bonica <[email protected]
<mailto:[email protected]>>
*Date:*Thursday, August 12, 2021 at 3:46 PM
*To:*"Acee Lindem (acee)" <[email protected]
<mailto:[email protected]>>, "[email protected]
<mailto:[email protected]>" <[email protected] <mailto:[email protected]>>
*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 <[email protected]
<mailto:[email protected]>>*On Behalf Of*Acee Lindem (acee)
*Sent:*Tuesday, August 10, 2021 4:43 PM
*To:*[email protected] <mailto:[email protected]>
*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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
