Shraddha - Regarding the new Generic Metric sub-TLV, there is a significant omission in the draft:
Given that (as you discuss in Sections 2.1 and 2.2) some metric types cannot be advertised in the new Generic Metric sub-TLV because they are specified to be advertised in a different encoding, it seems necessary to enhance the existing IGP Metric Types registry (https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-metric-type) to specify for each defined metric type whether it can/cannot be advertised in the Generic Metric sub-TLV. But you do not discuss extending the registry in this way at all in the draft. As I have stated in the past, I am not a big fan of the Generic Metric sub-TLV. I think it would be possible to do what you want to do without a generic container - but I am also amenable to what is in the draft. However, you MUST ensure that the IGP Metric Types registry is explicit as regards how each defined metric type (now and in the future) is advertised (inside the Generic Metric sub-TLV or not) I also think that the clarity of the presentation in Sections 2.1/2.2 could be enhanced by separating the text into multiple paragraphs. For example: <begin> The Generic Metric sub-TLV MAY be advertised multiple times. For a particular metric type, the Generic Metric sub-TLV MUST be advertised only once for a link when advertised in TLV 22,222,23,223 and 141. When Generic metric sub-TLV is advertised in ASLA, each metric type MUST be advertised only once per-application for a link. If there are multiple Generic Metric sub-TLVs advertised for a link for same metric type (and same application in case of ASLA) in one or more received LSPDUs, advertisement in the lowest numbered fragment MUST be used and the subsequent ones MUST be ignored. If the metric type indicates a standard metric type for which there are other advertisement mechanisms (e.g., the IGP metric, the Min Unidirectional Link Delay, or the Traffic Engineering Default Metric, as of this writing), the Generic Metric advertisement MUST be ignored. A metric value of 0xFFFFFF is considered as maximum link metric and a link having this metric value MUST NOT be considered in SPF computation. <end> Thanx. Les > -----Original Message----- > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Shraddha Hegde > Sent: Wednesday, January 11, 2023 9:01 PM > To: Acee Lindem <acee.i...@gmail.com>; lsr-...@ietf.org > Cc: lsr-cha...@ietf.org; draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org; lsr > <lsr@ietf.org> > Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt > > Acee, > > This draft defines a new metric-type called "bandwidth metric" and available > for use in flex-algo. > The specifics are described in section 4 of the draft. > Instead of defining a stand alone "bandwidth metric type", the draft defines > "generic metric" > Where there is a provision for metric-type/metric value pair. Defines > standard metric types and to make it > Flexible there is user defined metric-types > "Bandwidth metric" is one of the standard metric-types of the generic metric > that this draft > has defined and used. > > Rgds > Shraddha > > > Juniper Business Use Only > > -----Original Message----- > From: Acee Lindem <acee.i...@gmail.com> > Sent: Wednesday, January 11, 2023 11:44 PM > To: Shraddha Hegde <shrad...@juniper.net>; lsr-...@ietf.org > Cc: lsr-cha...@ietf.org; draft-ietf-lsr-flex-algo-bw-con.auth...@ietf.org; lsr > <lsr@ietf.org> > Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt > > [External Email. Be cautious of content] > > > +LSR List…. > > > Hi Shraddha, > > I’ll request the ADs approve early allocation. However, I recall unanswered > questions as to whether the generic metric was required and how it would > be used. It isn’t required for the bandwidth constraints defined in the > draft. > Can you comment on this point? > > Thanks, > Acee > > > On Jan 9, 2023, at 11:43 PM, Shraddha Hegde <shrad...@juniper.net> > wrote: > > > > Chairs, > > > > Authors would like to request IANA early code-point allocation for the > draft. > > > > Rgds > > Shraddha > > > > > > Juniper Business Use Only > > > > -----Original Message----- > > From: Lsr <lsr-boun...@ietf.org> On Behalf Of internet-dra...@ietf.org > > Sent: Tuesday, January 10, 2023 10:10 AM > > To: i-d-annou...@ietf.org > > Cc: lsr@ietf.org > > Subject: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-04.txt > > > > [External Email. Be cautious of content] > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Link State Routing WG of the IETF. > > > > Title : Flexible Algorithms: Bandwidth, Delay, Metrics and > Constraints > > Authors : Shraddha Hegde > > William Britto A J > > Rajesh Shetty > > Bruno Decraene > > Peter Psenak > > Tony Li > > Filename : draft-ietf-lsr-flex-algo-bw-con-04.txt > > Pages : 29 > > Date : 2023-01-09 > > > > Abstract: > > Many networks configure the link metric relative to the link > > capacity. High bandwidth traffic gets routed as per the link > > capacity. Flexible algorithms provides mechanisms to create > > constraint based paths in IGP. This draft documents a generic metric > > type and set of bandwidth related constraints to be used in Flexible > > Algorithms. > > > > > > > > The IETF datatracker status page for this draft is: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf- > lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!Db--a1RCey- > Q7ZXMSpU93MYIPyuVk4YeN_KLhIVN0FsLiqDW8ARDpp485WSQ6jtGcNg- > iL_V_VJkQ-71AZ8UPWiFZZw$ > > > > There is also an htmlized version available at: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft- > ietf-lsr-flex-algo-bw-con-04__;!!NEt6yMaO-gk!Db--a1RCey- > Q7ZXMSpU93MYIPyuVk4YeN_KLhIVN0FsLiqDW8ARDpp485WSQ6jtGcNg- > iL_V_VJkQ-71AZ8Use7KjRU$ > > > > A diff from the previous version is available at: > > https://urldefense.com/v3/__https://author- > tools.ietf.org/iddiff?url2=draft-ietf-lsr-flex-algo-bw-con-04__;!!NEt6yMaO- > gk!Db--a1RCey- > Q7ZXMSpU93MYIPyuVk4YeN_KLhIVN0FsLiqDW8ARDpp485WSQ6jtGcNg- > iL_V_VJkQ-71AZ8UFI_AgUI$ > > > > > > Internet-Drafts are also available by rsync at > > rsync.ietf.org::internet-drafts > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;! > !NEt6yMaO-gk!Db--a1RCey- > Q7ZXMSpU93MYIPyuVk4YeN_KLhIVN0FsLiqDW8ARDpp485WSQ6jtGcNg- > iL_V_VJkQ-71AZ8UhNjFf88$ > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
