'Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-ospf
Subject:    Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints
From:       "Les Ginsberg \(ginsberg\)" <ginsberg=40cisco.com () dmarc ! ietf ! org>
Date:       2021-08-20 18:57:09
Message-ID: BY5PR11MB4337F3E24152E8CBF7FAF668C1C19 () BY5PR11MB4337 ! namprd11 ! prod ! outlook ! com
[Download RAW message or body]

https://mailarchive.ietf.org/arch/msg/lsr/byaGtpjZACg4gSIziH3VFgAnYVU/

(Rereading the entire thread might be even more useful.)
Thanx.

   Les

> -----Original Message-----
> From: Ron Bonica <rbonica@juniper.net>
> Sent: Friday, August 20, 2021 9:46 AM
> To: Peter Psenak (ppsenak) <ppsenak@cisco.com>; Voyer, Daniel
> <daniel.voyer=40bell.ca@dmarc.ietf.org>; Voyer, Daniel
> <daniel.voyer@bell.ca>; Jeff Tantsura <jefftant.ietf@gmail.com>; Yingzhen
> Qu <yingzhen.ietf@gmail.com>
> Cc: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Acee Lindem (acee)
> <acee@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 <ppsenak@cisco.com>
> Sent: Friday, August 20, 2021 10:05 AM
> To: Voyer, Daniel <daniel.voyer=40bell.ca@dmarc.ietf.org>; Voyer, Daniel
> <daniel.voyer@bell.ca>; Jeff Tantsura <jefftant.ietf@gmail.com>; Yingzhen
> Qu <yingzhen.ietf@gmail.com>
> Cc: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Ron Bonica
> <rbonica@juniper.net>; Acee Lindem (acee) <acee@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-
> bounces@ietf.org on behalf of ppsenak=40cisco.com@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-bounces@ietf.org> on behalf of Jeff Tantsura
> > > <jefftant.ietf@gmail.com>
> > > *Date: *Thursday, August 19, 2021 at 8:14 PM
> > > *To: *Yingzhen Qu <yingzhen.ietf@gmail.com>
> > > *Cc: *"Les Ginsberg (ginsberg)"
> <ginsberg=40cisco.com@dmarc.ietf.org>,
> > > Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "Acee Lindem
> (acee)"
> > > <acee=40cisco.com@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.com@dmarc.ietf.org
> > > <mailto:ginsberg=40cisco.com@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-bounces@ietf.org
> > > <mailto:lsr-bounces@ietf.org>>*On Behalf Of*Ron Bonica
> > > *Sent:*Tuesday, August 17, 2021 11:21 AM
> > > *To:*Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org
> > > <mailto:acee=40cisco.com@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.com@dmarc.ietf.org
> > > <mailto:acee=40cisco.com@dmarc.ietf.org>>
> > > *Sent:*Friday, August 13, 2021 10:22 AM
> > > *To:*Ron Bonica <rbonica@juniper.net
> > > <mailto:rbonica@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-bounces@ietf.org <mailto:lsr-bounces@ietf.org>>
> > > on behalf of Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org
> > > <mailto:rbonica=40juniper.net@dmarc.ietf.org>>
> > > *Date:*Thursday, August 12, 2021 at 3:46 PM
> > > *To:*"Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org
> > > <mailto:acee=40cisco.com@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-bounces@ietf.org
> > > <mailto:lsr-bounces@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

[prev in list] [next in list] [prev in thread] [next in thread] 