Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
Hi All, wanted to record my +1 to the comment from Les on this matter. (there is no intent or desire to open this discussion again) G/ From: Lsr On Behalf Of Jeff Tantsura Sent: Friday, August 20, 2021 2:14 AM To: Yingzhen Qu Cc: Les Ginsberg (ginsberg) ; Ron Bonica ; Acee Lindem (acee) ; lsr@ietf.org Subject: 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) mailto: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 mailto:lsr-boun...@ietf.org>> On Behalf Of Ron Bonica Sent: Tuesday, August 17, 2021 11:21 AM To: Acee Lindem (acee) mailto:acee=40cisco@dmarc.ietf.org>>; lsr@ietf.org<mailto: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: 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 require
Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
https://mailarchive.ietf.org/arch/msg/lsr/byaGtpjZACg4gSIziH3VFgAnYVU/ (Rereading the entire thread might be even more useful.) Thanx. Les > -Original Message- > From: Ron Bonica > Sent: Friday, August 20, 2021 9:46 AM > To: Peter Psenak (ppsenak) ; Voyer, Daniel > ; Voyer, Daniel > ; Jeff Tantsura ; Yingzhen > Qu > Cc: Les Ginsberg (ginsberg) ; Acee Lindem (acee) > ; lsr@ietf.org > Subject: RE: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints > > Peter, > > I'm afraid that you have not answered Dan's question, or mine. > > The word "architecture" does not appear in RFC 8919 or RFC 8920. What > makes ASLA "the right thing"? > > Is "the architecture" codified in some document? If not, is there an agreed > upon architecture at all? > > Ron > > > Juniper Business Use Only > > -Original Message- > From: Peter Psenak > Sent: Friday, August 20, 2021 10:05 AM > To: Voyer, Daniel ; Voyer, Daniel > ; Jeff Tantsura ; Yingzhen > Qu > Cc: Les Ginsberg (ginsberg) ; Ron Bonica > ; Acee Lindem (acee) ; lsr@ietf.org > Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints > > [External Email. Be cautious of content] > > > Dan, > > On 20/08/2021 15:22, Voyer, Daniel wrote: > > Peter, > > > > On 2021-08-20, 8:46 AM, "Lsr on behalf of Peter Psenak" boun...@ietf.org on behalf of ppsenak=40cisco@dmarc.ietf.org> > wrote: > > > > Dan, > > > > On 20/08/2021 14:14, Voyer, Daniel wrote: > > > But generic-metric is a “new attribute” and is not in ASLA – RFC8919, > > > why can’t we use TLV 22 again ? > > because any new link attribute for which advertising application > > specific values make sense should use ASLA encoding. Metric is > > definitely such an attribute, similar to TE metric and delay (that is > > used as metric for flex-algo). > > > > But technically what prevent us to use TLV 22 ? it's out there already > > it's not about technically not being possible, it's about doing the right > thing > and following the existing architecture that has been defined for ASLA > already. > > thanks, > Peter > > > > > thanks, > > Peter > > > > > > > > > > > > *From: *Lsr on behalf of Jeff Tantsura > > > > > > *Date: *Thursday, August 19, 2021 at 8:14 PM > > > *To: *Yingzhen Qu > > > *Cc: *"Les Ginsberg (ginsberg)" > , > > > Ron Bonica , "Acee Lindem > (acee)" > > > , "lsr@ietf.org" > > > *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) > > > > > <mailto: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, 8
Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
Peter, I'm afraid that you have not answered Dan's question, or mine. The word "architecture" does not appear in RFC 8919 or RFC 8920. What makes ASLA "the right thing"? Is "the architecture" codified in some document? If not, is there an agreed upon architecture at all? Ron Juniper Business Use Only -Original Message- From: Peter Psenak Sent: Friday, August 20, 2021 10:05 AM To: Voyer, Daniel ; Voyer, Daniel ; Jeff Tantsura ; Yingzhen Qu Cc: Les Ginsberg (ginsberg) ; Ron Bonica ; Acee Lindem (acee) ; lsr@ietf.org Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints [External Email. Be cautious of content] Dan, On 20/08/2021 15:22, Voyer, Daniel wrote: > Peter, > > On 2021-08-20, 8:46 AM, "Lsr on behalf of Peter Psenak" on behalf of ppsenak=40cisco@dmarc.ietf.org> wrote: > > Dan, > > On 20/08/2021 14:14, Voyer, Daniel wrote: > > But generic-metric is a “new attribute” and is not in ASLA – RFC8919, > > why can’t we use TLV 22 again ? > because any new link attribute for which advertising application > specific values make sense should use ASLA encoding. Metric is > definitely such an attribute, similar to TE metric and delay (that is > used as metric for flex-algo). > > But technically what prevent us to use TLV 22 ? it's out there already it's not about technically not being possible, it's about doing the right thing and following the existing architecture that has been defined for ASLA already. thanks, Peter > > thanks, > Peter > > > > > > > *From: *Lsr on behalf of Jeff Tantsura > > > > *Date: *Thursday, August 19, 2021 at 8:14 PM > > *To: *Yingzhen Qu > > *Cc: *"Les Ginsberg (ginsberg)" , > > Ron Bonica , "Acee Lindem (acee)" > > , "lsr@ietf.org" > > *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) > > > <mailto: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 rule
Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
Dan,
On 20/08/2021 15:22, Voyer, Daniel wrote:
Peter,
On 2021-08-20, 8:46 AM, "Lsr on behalf of Peter Psenak" wrote:
Dan,
On 20/08/2021 14:14, Voyer, Daniel wrote:
> But generic-metric is a “new attribute” and is not in ASLA – RFC8919,
> why can’t we use TLV 22 again ?
because any new link attribute for which advertising application
specific values make sense should use ASLA encoding. Metric is
definitely such an attribute, similar to TE metric and delay (that is
used as metric for flex-algo).
But technically what prevent us to use TLV 22 ? it's out there already
it's not about technically not being possible, it's about doing the
right thing and following the existing architecture that has been
defined for ASLA already.
thanks,
Peter
thanks,
Peter
>
> *From: *Lsr on behalf of Jeff Tantsura
>
> *Date: *Thursday, August 19, 2021 at 8:14 PM
> *To: *Yingzhen Qu
> *Cc: *"Les Ginsberg (ginsberg)" ,
> Ron Bonica , "Acee Lindem (acee)"
> , "lsr@ietf.org"
> *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)
> <mailto: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 <mailto:lsr-boun...@ietf.org>>*On Behalf Of*Ron Bonica
> *Sent:*Tuesday, August 17, 2021 11:21 AM
> *To:*Acee Lindem (acee) <
Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
Peter,
On 2021-08-20, 8:46 AM, "Lsr on behalf of Peter Psenak" wrote:
Dan,
On 20/08/2021 14:14, Voyer, Daniel wrote:
> But generic-metric is a “new attribute” and is not in ASLA – RFC8919,
> why can’t we use TLV 22 again ?
because any new link attribute for which advertising application
specific values make sense should use ASLA encoding. Metric is
definitely such an attribute, similar to TE metric and delay (that is
used as metric for flex-algo).
But technically what prevent us to use TLV 22 ? it's out there already
thanks,
Peter
>
> *From: *Lsr on behalf of Jeff Tantsura
>
> *Date: *Thursday, August 19, 2021 at 8:14 PM
> *To: *Yingzhen Qu
> *Cc: *"Les Ginsberg (ginsberg)" ,
> Ron Bonica , "Acee Lindem (acee)"
> , "lsr@ietf.org"
> *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)
> <mailto: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 <mailto:lsr-boun...@ietf.org>>*On Behalf Of*Ron Bonica
> *Sent:*Tuesday, August 17, 2021 11:21 AM
> *To:*Acee Lindem (acee) <mailto:acee=40cisco@dmarc.ietf.org>>;lsr@ietf.org
> <mailto:lsr@ietf.org>
> *Subject:*Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo
> BW Constraints
>
> Acee,
>
> S
Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
Dan,
On 20/08/2021 14:14, Voyer, Daniel wrote:
But generic-metric is a “new attribute” and is not in ASLA – RFC8919,
why can’t we use TLV 22 again ?
because any new link attribute for which advertising application
specific values make sense should use ASLA encoding. Metric is
definitely such an attribute, similar to TE metric and delay (that is
used as metric for flex-algo).
thanks,
Peter
*From: *Lsr on behalf of Jeff Tantsura
*Date: *Thursday, August 19, 2021 at 8:14 PM
*To: *Yingzhen Qu
*Cc: *"Les Ginsberg (ginsberg)" ,
Ron Bonica , "Acee Lindem (acee)"
, "lsr@ietf.org"
*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)
mailto: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 mailto:lsr-boun...@ietf.org>>*On Behalf Of*Ron Bonica
*Sent:*Tuesday, August 17, 2021 11:21 AM
*To:*Acee Lindem (acee) mailto:acee=40cisco@dmarc.ietf.org>>;lsr@ietf.org
<mailto: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 reservation
Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
But generic-metric is a “new attribute” and is not in ASLA – RFC8919, why can’t we use TLV 22 again ? From: Lsr on behalf of Jeff Tantsura Date: Thursday, August 19, 2021 at 8:14 PM To: Yingzhen Qu Cc: "Les Ginsberg (ginsberg)" , Ron Bonica , "Acee Lindem (acee)" , "lsr@ietf.org" 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) mailto: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 mailto:lsr-boun...@ietf.org>> On Behalf Of Ron Bonica Sent: Tuesday, August 17, 2021 11:21 AM To: Acee Lindem (acee) mailto:acee=40cisco@dmarc.ietf.org>>; lsr@ietf.org<mailto: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: 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, bec
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) >> 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 On Behalf Of Ron Bonica >> Sent: Tuesday, August 17, 2021 11:21 AM >> To: Acee Lindem (acee) ; 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 infor
Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
I have been following the discussions on the list, and here comes my $0.02: ASLA provides a generic mechanism of associating different applications and link attributes. The WG reached consensus of this architecture after long debate, so my understanding is new proposals should follow this path unless it’s impossible to use ASLA to define the new attributes. So far I’m not convinced by the discussions on the list that draft-ietf-lsr-flex-algo-bw-con can not use ASLA and has to specify an alternative, and the alternative is better. Thanks, Yingzhen > On Aug 18, 2021, at 1:20 PM, Les Ginsberg (ginsberg) > 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 mailto:lsr-boun...@ietf.org>> On Behalf Of > Ron Bonica > Sent: Tuesday, August 17, 2021 11:21 AM > To: Acee Lindem (acee) <mailto:acee=40cisco@dmarc.ietf.org>>; lsr@ietf.org <mailto: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 > infor
Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
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 On Behalf Of Ron Bonica Sent: Tuesday, August 17, 2021 11:21 AM To: Acee Lindem (acee) ; 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: 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) mailto:acee=40cisco@dmarc.ietf.org>> Sent: Friday, August 13, 2021 10:22 AM To: Ron Bonica mailto:rbon...@jun
Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
See more inline… From: Acee Lindem Date: Wednesday, August 18, 2021 at 2:38 PM To: Ron Bonica , "lsr@ietf.org" Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints Hi Ron, From: Ron Bonica Date: Tuesday, August 17, 2021 at 2:20 PM To: Acee Lindem , "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: 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 having trouble envisioning this whole solution where bandwidth for Flex Algo constraints is configured centrally. But in any case, the Robert indicated how one could advertise an ASLA for all applications. I can see how the min-bandwidth, maximum delay, reference bandwidth, and threshold bandwidths would be global for a flex algorithm constraints. However, I can’t see how bandwidth for an individual link on a specific node would be applicable to anything but that link and node for the flex algorithm application. Thanks, Acee Thanks, Acee Ron Juniper Business Use Only From: Acee Lindem (acee) Sent: Friday, August 13, 2021 10:22 AM To: Ron Bonica ; 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 mailto:lsr-boun...@ietf.org>> on behalf of Ron Bonica mailto:rbonica=40juniper@dmarc.ietf.org>> Date: Thursday, August 12, 2021 at 3:46 PM To: "Acee Lindem (acee)" mailto:acee=40cisco@dmarc.ietf.org>>, "lsr@ietf.org<mailto: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 pr
Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
Hi Ron, From: Ron Bonica Date: Tuesday, August 17, 2021 at 2:20 PM To: Acee Lindem , "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: 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 having trouble envisioning this whole solution where bandwidth for Flex Algo constraints is configured centrally. But in any case, the Robert indicated how one could advertise an ASLA for all applications. Thanks, Acee Ron Juniper Business Use Only From: Acee Lindem (acee) Sent: Friday, August 13, 2021 10:22 AM To: Ron Bonica ; 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 mailto:lsr-boun...@ietf.org>> on behalf of Ron Bonica mailto:rbonica=40juniper@dmarc.ietf.org>> Date: Thursday, August 12, 2021 at 3:46 PM To: "Acee Lindem (acee)" mailto:acee=40cisco@dmarc.ietf.org>>, "lsr@ietf.org<mailto: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 mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem (acee) Sent: Tuesday, August 10, 202
Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
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) *Sent:* Friday, August 13, 2021 10:22 AM *To:* Ron Bonica ; 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 mailto:lsr-boun...@ietf.org>> on behalf of Ron Bonica <mailto:rbonica=40juniper@dmarc.ietf.org>> *Date: *Thursday, August 12, 2021 at 3:46 PM *To: *"Acee Lindem (acee)" <mailto:acee=40cisco@dmarc.ietf.org>>, "lsr@ietf.org <mailto: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 mailto:lsr-boun...@ietf.org>> *On Behalf Of *Acee Lindem (acee) *Sent:* Tuesday, August 10, 2021 4:43 PM *To:* lsr
Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
Hi Ron, So here is the suggestion ... Currently the encoded values of SABM are: SABM (variable length): Standard Application Identifier Bit Mask (SABM Length * 8) bits This field is omitted if SABM Length is 0. 0 1 2 3 4 5 6 7 ... +-+-+-+-+-+-+-+-+... |R|S|F|X|... +-+-+-+-+-+-+-+-+... R-bit: Set to specify RSVP-TE. S-bit: Set to specify Segment Routing Policy. F-bit: Set to specify Loop-Free Alternate (LFA) (includes all LFA types). X-bit: Set to specify Flexible Algorithm How about you write a one page draft to specify bit #4 * A-bit: Set to specify all applications - current and future. * I am not sure if this is really needed (as one could easily just set all bits R, S F to 1, but maybe when we have 1000 applications and you have a metric which should apply to all of them you just would be better to set A-bit and be done ? On another note as mentioned before I do agree with Shraddha about Flex Algo just using one bit is not enough. If I run two or N topologies each should have its own bit. At least SABM should define few for flex algo and if more is needed we go to UDABM. Best, Robert On Tue, Aug 17, 2021 at 9:58 PM Ron Bonica wrote: > Robert, > > > > The following information types need to be distributed : > > > >1. Application Independent Link Attributes > 1. Mentioned in Section 3.2 of RFC 8919 > 2. Not mentioned in Section 3.2 of RFC 8919 >2. Application Configuration Information that is associated with an >interface >3. Application Information that is not associated with an interface > > > > Section 6.1 of RFC 8919 addresses information of Type 1a). Under some > conditions, it can be advertised as described in RFC 5305. In other > conditions, it must be advertised as ASLA. > > > > Information of Type 1b) should by advertised as were the TE attributes > defined in RFC 5305 (i.e., outside of the ASLA context). > > > > Information of Type 2 should be advertises as ASLA. > > > > Information of Type 3 should be considered on an application by > application basis. For Flexalgo, it should be advertised in the FAD. > > > > > >Ron > > > > > > Juniper Business Use Only > > *From:* Robert Raszuk > *Sent:* Tuesday, August 17, 2021 2:52 PM > *To:* Ron Bonica > *Cc:* Acee Lindem (acee) ; lsr@ietf.org > *Subject:* Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW > Constraints > > > > *[External Email. Be cautious of content]* > > > > 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 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 >
Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
Robert, The following information types need to be distributed : 1. Application Independent Link Attributes * Mentioned in Section 3.2 of RFC 8919 * Not mentioned in Section 3.2 of RFC 8919 2. Application Configuration Information that is associated with an interface 3. Application Information that is not associated with an interface Section 6.1 of RFC 8919 addresses information of Type 1a). Under some conditions, it can be advertised as described in RFC 5305. In other conditions, it must be advertised as ASLA. Information of Type 1b) should by advertised as were the TE attributes defined in RFC 5305 (i.e., outside of the ASLA context). Information of Type 2 should be advertises as ASLA. Information of Type 3 should be considered on an application by application basis. For Flexalgo, it should be advertised in the FAD. Ron Juniper Business Use Only From: Robert Raszuk Sent: Tuesday, August 17, 2021 2:52 PM To: Ron Bonica Cc: Acee Lindem (acee) ; lsr@ietf.org Subject: Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints [External Email. Be cautious of content] 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 mailto: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) mailto:40cisco@dmarc.ietf.org>> Sent: Friday, August 13, 2021 10:22 AM To: Ron Bonica mailto:rbon...@juniper.net>>; lsr@ietf.org<mailto: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 w
Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
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 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) > *Sent:* Friday, August 13, 2021 10:22 AM > *To:* Ron Bonica ; 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 on behalf of Ron Bonica < > rbonica=40juniper@dmarc.ietf.org> > *Date: *Thursday, August 12, 2021 at 3:46 PM > *To: *"Acee Lindem (acee)" , " > 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 tec
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) Sent: Friday, August 13, 2021 10:22 AM To: Ron Bonica ; 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 mailto:lsr-boun...@ietf.org>> on behalf of Ron Bonica mailto:rbonica=40juniper@dmarc.ietf.org>> Date: Thursday, August 12, 2021 at 3:46 PM To: "Acee Lindem (acee)" mailto:acee=40cisco@dmarc.ietf.org>>, "lsr@ietf.org<mailto: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 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
Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
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 on behalf of Ron Bonica Date: Thursday, August 12, 2021 at 3:46 PM To: "Acee Lindem (acee)" , "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 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
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 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] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
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
