Gyan – This question has been clearly addressed by Peter in his most recent post:
<snip> 2. Generic Metric is not something that must be defined as application independent, on the contrary, it's a value that is either assigned by operator or computed somehow. Advertising application specific values not only make sense, but would add value. TE metric is an example which is very close to Generic Metric and is supported in ASLA. <end snip> Please read his email for the complete response. Les From: Gyan Mishra <hayabusa...@gmail.com> Sent: Friday, July 23, 2021 8:26 AM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> Cc: Acee Lindem (acee) <a...@cisco.com>; Peter Psenak (ppsenak) <ppse...@cisco.com>; Ron Bonica <rbon...@juniper.net>; Shraddha Hegde <shrad...@juniper.net>; draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org; gregory.mir...@ztetx.com; lsr@ietf.org Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt I believe the gap is whether or not the Generic metric is like maximum bandwidth link attribute which is application independent and based on the use case in this draft of the WG can be convinced that this use case is for application independent. In RFC 8919 and RFC 8920 the normative language was chosen precisely for that purpose so that on a case by case basis for a an link attribute to be deemed ASLA or application independent. Kind Regards Gyan On Thu, Jul 22, 2021 at 3:44 PM Gyan Mishra <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>> wrote: As stated nicely by Les, the goal and intent of RFC 8919 and 8920 as stated clearly was meant to fix a ambiguities related to cases where multiple applications RSVP-TE, SR, Flex Algo making use of link attributes by creating ASLA for a list of link attributes sub-tlv’s that existed at time of writing the document, however moving forward that all new link attributes defined MUST now be advertised using ASLA sub tlv. By not doing do you are perpetuating the problem all over again. The chairs and other in the WG would like to draw a line in the sand that any new link attribute MUST be advertised using ASLA SUB-TLV encoding. RFC 8919 -Last paragraph in the introduction This document defines extensions that address these issues. Also, as evolution of use cases for link attributes can be expected to continue in the years to come, this document defines a solution that is easily extensible to the introduction of new applications and new use cases. RFC 8920- Last paragraph in the introduction This document defines extensions that address these issues. Also, as evolution of use cases for link attributes can be expected to continue in the years to come, this document defines a solution that is easily extensible for the introduction of new applications and new use cases. The key is the extensibility of RFC 8919 and RFC 8920 for all future link attributes and not just the ones defined when the draft was written. Kind Regards Gyan On Thu, Jul 22, 2021 at 2:49 PM Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> wrote: Ron - With respect, it is hard to read your email without feeling that it is disingenuous. But, let's cover the relevant points nonetheless. Point #1: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-17#section-12 states: " Link attribute advertisements that are to be used during Flex- Algorithm calculation MUST use the Application-Specific Link Attribute (ASLA) advertisements defined in [RFC8919] or [RFC8920]..." As the new generic-metric is intended for use by flex-algo it needs to conform to this normative statement. Point #2: RFC 8919 and 8920 were written to address ambiguities associated with the use of multiple applications. The Introduction sections of both documents discuss this in some detail. The clear intent is to make use of ASLA going forward - not to restrict ASLA only to the set of link attributes defined at the time of the writing of the RFCs. Failure to do so would reintroduce the same set of issues that RFC 8919/8920 were written to address. Your attempt to infer that because Generic-Metric was not defined at the time that RFC 8919/8920 were written that the RFCs don’t apply to it makes no sense. ASLA is in fact a revision to the link attribute architecture and is meant to be used going forward. The more appropriate question to ask is why we need to define a legacy style sub-TLV for new link attributes? Ketan has made this point in his post on this thread and I have sympathy with his position. We do understand that legacy applications such as RSVP-TE may continue to be deployed in networks for some time to come. It is not reasonable to expect that legacy application implementations will be updated to use ASLA, which is why I do not object to defining a legacy style encoding for Generic Metric if folks believe that legacy applications may be enhanced to support new link attributes. I strongly disagree with your interpretation that ASLA is limited only to the code points defined in RFC 8919/8920. Les > -----Original Message----- > From: Ron Bonica > <rbonica=40juniper....@dmarc.ietf.org<mailto:40juniper....@dmarc.ietf.org>> > Sent: Thursday, July 22, 2021 10:28 AM > To: Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>>; Les Ginsberg > (ginsberg) > <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; Shraddha Hegde > <shrad...@juniper.net<mailto:shrad...@juniper.net>>; > gregory.mir...@ztetx.com<mailto:gregory.mir...@ztetx.com>; Peter Psenak > (ppsenak) <ppse...@cisco.com<mailto:ppse...@cisco.com>>; > lsr@ietf.org<mailto:lsr@ietf.org> > Cc: > draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org<mailto:draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org> > Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt > > Acee, > > I don't think that draft-ietf-lsr-flex-algo-bw-con violates RFC 8919. > > Section 6.1 of RFC 8919 says: > > " New applications that future documents define to make use of the > advertisements defined in this document MUST NOT make use of legacy > advertisements. This simplifies deployment of new applications by > eliminating the need to support multiple ways to advertise attributes > for the new applications." > > Section 3 of RFC 8919 defines legacy advertisements. The definition of legacy > advertisements does not include new attributes such as > generic metric. Therefore draft-ietf-lsr-flex-algo-bw-con does not > violate RFC 8919 > > Relevant text from Section 3 of RFC 8919 is included below for convenience. > > Ron > > > RFC 8919, Section 3 > --------------------------- > 3. Legacy Advertisements > > > Existing advertisements used in support of RSVP-TE include sub-TLVs > for TLVs 22, 23, 25, 141, 222, and 223 and TLVs for Shared Risk Link > Group (SRLG) advertisement. > > Sub-TLV values are defined in the "Sub-TLVs for TLVs 22, 23, 25, 141, > 222, and 223" registry. > > TLVs are defined in the "TLV Codepoints Registry". > > 3.1. Legacy Sub-TLVs > > +======+====================================+ > | Type | Description | > +======+====================================+ > | 3 | Administrative group (color) | > +------+------------------------------------+ > | 9 | Maximum link bandwidth | > +------+------------------------------------+ > | 10 | Maximum reservable link bandwidth | > +------+------------------------------------+ > | 11 | Unreserved bandwidth | > +------+------------------------------------+ > | 14 | Extended Administrative Group | > +------+------------------------------------+ > | 18 | TE Default Metric | > +------+------------------------------------+ > | 33 | Unidirectional Link Delay | > +------+------------------------------------+ > | 34 | Min/Max Unidirectional Link Delay | > +------+------------------------------------+ > | 35 | Unidirectional Delay Variation | > +------+------------------------------------+ > | 36 | Unidirectional Link Loss | > +------+------------------------------------+ > | 37 | Unidirectional Residual Bandwidth | > +------+------------------------------------+ > | 38 | Unidirectional Available Bandwidth | > +------+------------------------------------+ > | 39 | Unidirectional Utilized Bandwidth | > +------+------------------------------------+ > > Table 1: Sub-TLVs for TLVs 22, 23, 25, > 141, 222, and 223 > > > > Juniper Business Use Only > > -----Original Message----- > From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of > Acee Lindem (acee) > Sent: Tuesday, July 20, 2021 1:21 PM > To: Les Ginsberg (ginsberg) > <ginsberg=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>>; > Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>; > gregory.mir...@ztetx.com<mailto:gregory.mir...@ztetx.com>; > ppsenak=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>; > lsr@ietf.org<mailto:lsr@ietf.org> > Cc: > draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org<mailto:draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org> > Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt > > [External Email. Be cautious of content] > > > Speaking as WG member: > > I agree with Les. The Generic Metric MUST be advertised as an ASLA for > usage in Flex Algorithm. Additionally, it may be advertised as a sub-TLV in > IS- > IS link TLVs. However, the latter encoding really shouldn't be used for new > applications (at least that is my reading of RFC 8919). > > For OSPF, I'd certainly hope one wouldn't originate additional LSAs when an > ASLA can support the legacy applications with the ASLA mask. > > Thanks, > Acee > > _______________________________________________ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr -- [Image removed by sender.]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com> M 301 502-1347 -- [Image removed by sender.]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com> M 301 502-1347
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
