https://mailarchive.ietf.org/arch/msg/lsr/byaGtpjZACg4gSIziH3VFgAnYVU/
(Rereading the entire thread might be even more useful.) Thanx. Les > -----Original Message----- > From: Ron Bonica <rbon...@juniper.net> > Sent: Friday, August 20, 2021 9:46 AM > To: Peter Psenak (ppsenak) <ppse...@cisco.com>; Voyer, Daniel > <daniel.voyer=40bell...@dmarc.ietf.org>; Voyer, Daniel > <daniel.vo...@bell.ca>; Jeff Tantsura <jefftant.i...@gmail.com>; Yingzhen > Qu <yingzhen.i...@gmail.com> > Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Acee Lindem (acee) > <a...@cisco.com>; 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 <ppse...@cisco.com> > Sent: Friday, August 20, 2021 10:05 AM > To: Voyer, Daniel <daniel.voyer=40bell...@dmarc.ietf.org>; Voyer, Daniel > <daniel.vo...@bell.ca>; Jeff Tantsura <jefftant.i...@gmail.com>; Yingzhen > Qu <yingzhen.i...@gmail.com> > Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Ron Bonica > <rbon...@juniper.net>; Acee Lindem (acee) <a...@cisco.com>; 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" <lsr- > 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 <lsr-boun...@ietf.org> on behalf of Jeff Tantsura > > > <jefftant.i...@gmail.com> > > > *Date: *Thursday, August 19, 2021 at 8:14 PM > > > *To: *Yingzhen Qu <yingzhen.i...@gmail.com> > > > *Cc: *"Les Ginsberg (ginsberg)" > <ginsberg=40cisco....@dmarc.ietf.org>, > > > Ron Bonica <rbonica=40juniper....@dmarc.ietf.org>, "Acee Lindem > (acee)" > > > <acee=40cisco....@dmarc.ietf.org>, "lsr@ietf.org" <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) > > > <ginsberg=40cisco....@dmarc.ietf.org > > > <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 <lsr-boun...@ietf.org > > > <mailto:lsr-boun...@ietf.org>>*On Behalf Of*Ron Bonica > > > *Sent:*Tuesday, August 17, 2021 11:21 AM > > > *To:*Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org > > > <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 > > > requires configuration on each node. Option 3 is better > > because: > > > > > > * It requires configuration on only a few nodes > > > * It maintains separation between link attributes and > > > application configuration information > > > * It can support applications like Flexalgo, where each > > > algorithm may use different link attributes to calculate > > the > > > shortest path > > > > > > > > Ron > > > > > > Juniper Business Use Only > > > > > > *From:*Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org > > > <mailto:acee=40cisco....@dmarc.ietf.org>> > > > *Sent:*Friday, August 13, 2021 10:22 AM > > > *To:*Ron Bonica <rbon...@juniper.net > > > <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 way of encoding link attributes > > for > > > different applications. > > > > > > Thanks, > > > > > > Acee > > > > > > *From:*Lsr <lsr-boun...@ietf.org > > <mailto:lsr-boun...@ietf.org>> > > > on behalf of Ron Bonica <rbonica=40juniper....@dmarc.ietf.org > > > <mailto:rbonica=40juniper....@dmarc.ietf.org>> > > > *Date:*Thursday, August 12, 2021 at 3:46 PM > > > *To:*"Acee Lindem (acee)" <acee=40cisco....@dmarc.ietf.org > > > <mailto:acee=40cisco....@dmarc.ietf.org>>, "lsr@ietf.org > > > <mailto:lsr@ietf.org>" <lsr@ietf.org <mailto:lsr@ietf.org>> > > > *Subject:*Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex > > Algo > > > BW Constraints > > > > > > Acee, > > > > > > Please help me to parse your message. It is clear that you > > want > > > draft-ietf-lsr-flex-algo-bw-con to specify ASLA’s. However, > > your > > > rationale is not so clear. > > > > > > It is not because RFC 8919 mandates ASLA. In fact, we agree > > that > > > it would be strange for an RFC to include a mandate that > > > precludes future proposals. > > > > > > Are any of the following your rationale: > > > > > > 1)Because there is a good technical reason for > > > draft-ietf-lsr-flex-algo-bw-con to specify ASLA > > > > > > 2)Because it is possible, but not necessary, for > > > draft-ietf-lsr-flex-algo-bw-con to specify ASLA > > > > > > 3)Because it was the unstated intention of RFC 8919 to > > include a > > > mandate that precludes future proposals (although we agree > > that > > > this would be strange). > > > > > > For the purposes of full disclosure, I think discussion > > > regarding the first rationale would be fruitful. However, I > > > don’t think very much of the second or third rationale. > > > > > > > > > > Ron > > > > > > Juniper Business Use Only > > > > > > *From:*Lsr <lsr-boun...@ietf.org > > > <mailto:lsr-boun...@ietf.org>>*On Behalf Of*Acee Lindem > (acee) > > > *Sent:*Tuesday, August 10, 2021 4:43 PM > > > *To:*lsr@ietf.org <mailto:lsr@ietf.org> > > > *Subject:*[Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo > > BW > > > Constraints > > > > > > *[External Email. Be cautious of content]* > > > > > > Speaking as a WG Member: > > > > > > In reviewing RFC 8919 and RFC 8920, it is clear that the > > ASLA > > > mechanism was to be used for new link attributes and > > > applications. While the documents do not mandate that there > > > never could be a new way to advertise link attributes, this > > was > > > clearly the intent. Indeed, it would be strange for an RFC to > > > include a mandate that precluded future proposals. The > > > advertisement enablement and deployment sections of these > > > documents specifically cover future attributes and > > applications. > > > > > > Given that we have ASLAs as building blocks, I don’t > > really > > > see a reason to introduce the generic metric. The proponents > > say > > > it isn’t an alternative to ASLAs but their examples cite > > > different applications using different metric types (i.e., > > > application-specific metrics). Also, given that ASLA are > > used by > > > the base Flex Algo draft, it would be inconsistent to diverge > > > for Flex Algo BW constraints. > > > > > > Consequently, I would request that > > > draft-ietf-lsr-flex-algo-bw-con-01 revert to using ASLAs. > > Based > > > on the LSR Email discussion prior to IETF 111, this was > > > definitely the consensus. > > > > > > Thanks, > > > Acee > > > > > > _______________________________________________ > > > Lsr mailing list > > > Lsr@ietf.org <mailto:Lsr@ietf.org> > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;! > !NEt6yMaO-gk!QhNdCvBCL468T_xtPFJ2qsz7hlfjcAgO45hdj24OO1wg9zI- > AOF91KTglVLvW4rp$ > > > > > > _______________________________________________ > > > Lsr mailing list > > > Lsr@ietf.org > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;! > !NEt6yMaO-gk!QhNdCvBCL468T_xtPFJ2qsz7hlfjcAgO45hdj24OO1wg9zI- > AOF91KTglVLvW4rp$ > > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > > 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
