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 <[email protected]>
Sent: Friday, August 20, 2021 10:05 AM
To: Voyer, Daniel <[email protected]>; Voyer, Daniel
<[email protected]>; Jeff Tantsura <[email protected]>; Yingzhen Qu
<[email protected]>
Cc: Les Ginsberg (ginsberg) <[email protected]>; Ron Bonica
<[email protected]>; Acee Lindem (acee) <[email protected]>; [email protected]
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" <[email protected]
> on behalf of [email protected]> 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 <[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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!QhNdCvBCL468T_xtPFJ2qsz7hlfjcAgO45hdj24OO1wg9zI-AOF91KTglVLvW4rp$
> >
> > _______________________________________________
> > Lsr mailing list
> > [email protected]
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!QhNdCvBCL468T_xtPFJ2qsz7hlfjcAgO45hdj24OO1wg9zI-AOF91KTglVLvW4rp$
> >
>
> _______________________________________________
> Lsr mailing list
> [email protected]
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!QhNdCvBCL468T_xtPFJ2qsz7hlfjcAgO45hdj24OO1wg9zI-AOF91KTglVLvW4rp$
>
> ------------------------------------------------------------------------------
> External Email: Please use caution when opening links and
> attachments / Courriel externe: Soyez prudent avec les liens et
> documents joints
>
>
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
