Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt

[Gyan Mishra <[e-mail]>]

Ketan brought up this  valid concern during the adoption call in May.

This is a valid concern and I am in agreement with Acee, Les, and Peter
that the Generic metric TLV for Flex Algorithm  is not a legacy
advertisement and is application specific.

Therefore, this Generic Metric defined in this draft, as it’s not legacy
per RFC 8920 OSPF ASLA and RFC 8919 ISIS ASLA, and as is a new application,
it MUST use ASLA advertisement.

I would support progressing this draft if the authors are willing to use
ALSA for this use application with Flex Algorithm and not application
independent path.

Kind Regards

Gyan



On Tue, Jul 20, 2021 at 1:21 PM Acee Lindem (acee) <acee=
[e-mail]> wrote:

> 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
>
> On 7/19/21, 2:45 PM, "Lsr on behalf of Les Ginsberg (ginsberg)" <
> [e-mail] on behalf of ginsberg=[e-mail]>
> wrote:
>
>     Shraddha -
>
>     With respect, the issue here is very simple and does not warrant the
> long email.
>
>     As per RFC 8919/8920, any link attribute used by applications defined
> with an ASLA bit (other than the legacy applications RSVP-TE, SRTE, and
> LFA) MUST use ASLA advertisements.
>     As you propose to use the new metric for Flex-Algo - which is a "new
> application" with an ASLA assigned bit - you MUST support ASLA encoding.
>     You can also support encoding in a sub-TLV under TLV22 (etc.).
>
>     There is nothing to discuss here - it is simply a matter of conforming
> to the normative statements in existing RFCs.
>
>     Please correct the draft as requested.
>
>        Les
>
>
>     > -----Original Message-----
>     > From: Shraddha Hegde <[e-mail]>
>     > Sent: Monday, July 19, 2021 11:05 AM
>     > To: [e-mail]; ppsenak=[e-mail];
>     > [e-mail]
>     > Cc: Les Ginsberg (ginsberg) <[e-mail]>;
> draft-ietf-lsr-flex-algo-
>     > [e-mail]
>     > Subject: RE: Re:[Lsr] I-D Action:
> draft-ietf-lsr-flex-algo-bw-con-01.txt
>     >
>     > Hi All,
>     >
>     > Generic metric was allowed to be advertised in TLV 22/ ELO LSA
>     > as well as ASLA TLV before the draft was called for adoption.
>     > During the recent WG adoption review, it was pointed out that
>     > ASLA architecture does not allow an attribute to be advertised
>     > in both application-specific and application-independent manner.
>     >
>     > As a result of this Generic metric has been made an
>     > application-independent attribute in the latest version.
>     > The reasons are below
>     >
>     > 1.Generic metric is required to be advertised in an
> application-independent
>     > manner
>     > that is metric-type 128 is advertised for a link and any application
>     > like flex-algo, SR-TE, RSVP LFA can make use of it.
>     > Metric has scope outside of an IGP domain. It gets advertised
>     > in BGP-LU and gets accumulated across domains.
>     > There are many usecases that will benefit from advertising
> generic-metric
>     > in an application-independent manner.
>     >
>     > 2.The recent case of te-metric usecase that I came across
>     > where ASLA was being used, really wanted to
>     > use a different metric-type for flex-algo and not really
>     > different values for same metric type.
>     > (Peter, coincidently we may be talking of the same recent
>     > usecase which you claimed to be using ASLA)
>     >
>     > 3.Advertising generic metric in an application independent manner in
> legacy
>     > TLV 22 and ELO LSA
>     > does not violate RFC 8919/8920. Application-independent attributes
> are not
>     > expected to use RFC 8919/8920
>     > mechanisms. Generic metric is like igp cost. IGP-cost is never
> advertised in
>     > ASLA but it gets used in flex-algo
>     > and generic-metric is being modeled based on igp-cost.
>     > As currently written, this document is compliant to every RFC and
> draft that
>     > has
>     > been out there and not violating any of them.
>     >
>     > 4.Generic metric is very flexible. It allows for finest granularity
> of
>     > metric advertisement.
>     > Usecase:
>     > Lets say flex-algo 128 wants to use metric-type 128 and flex-algo 129
>     > wants to use metric-type 129. An year later operator decides to
> deploy
>     > SR-TE with red LSPs using metric-type 128 and Blue LSPs using
> metric-type
>     > 129.
>     >
>     > Using generic metric in application-independent manner:
>     > 1.configure metric-type 128 and 129 and value pair on each link
>     > 2. set flex-algo 128 FAD to use metric-type 128 and flex-algo FAD
> 129 to use
>     > metric-type 129
>     > 3. An year later configure Red LSPs to use metric-type 128 and Blue
> LSPs to
>     > use metric-type 129
>     >
>     > Using generic metric with ASLA:
>     > 1. Define user defined bit-masks for flex-algo 128 and flex-algo 129
> and
>     > configure on every router
>     > 2. configure metric-type 128 and 129 on every link
>     > 3. An year later, define user defined bit masks  for SR-TE Red LSPs
> and SR-TE
>     > blue LSPs
>     > 4. Configure the bit masks on all head-end routers
>     > 5. Associate the new bit masks with the metric-types on every router
> on
>     > every link.
>     >
>     > The most common cases look operationally very complex with ASLA while
>     > they look very
>     > simple operationally with generic-metric being advertised in an
> application-
>     > independent
>     > manner. It looks reasonable approach to allow the option of
> application-
>     > independent
>     > advertisements for operators who are looking to simplify operations.
>     >
>     >
>     > In order to decide  how the generic-metric should be advertised, it
> would
>     > be good to get input from the WG on below point.
>     >  Do you have usecases in mind that you would like to deploy that
> cannot be
>     > solved
>     > with advertising generic-metric in an application-independent manner?
>     >
>     >
>     > Looking forward to more discussions during LSR WG meeting.
>     >
>     >
>     > Rgds
>     > Shraddha
>     >
>     >
>     > Juniper Business Use Only
>     >
>     > -----Original Message-----
>     > From: [e-mail] <[e-mail]>
>     > Sent: Sunday, July 18, 2021 2:11 AM
>     > To: ppsenak=[e-mail]; [e-mail]
>     > Cc: [e-mail];
> [e-mail]
>     > Subject: Re:[Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
>     >
>     > [External Email. Be cautious of content]
>     >
>     >
>     > Dear All,
>     > I concur with the arguments presented by Les and Peter. Perhaps the
> Editors
>     > of the WG draft will update the document accordingly.
>     >
>     > Regards,
>     > Greg Mirsky
>     > Sr. Standardization Expert
>     > 预研标准部/有线研究院/有线产品经营部  Standard Preresearch
>     > Dept./Wireline Product R&D Institute/Wireline Product Operation
> Division
>     > E: [e-mail]
>     > www.zte.com.cn
>     > ------------------Original Mail------------------
>     > Sender: PeterPsenak
>     > To: Les Ginsberg (ginsberg);[e-mail]
> ;draft-ietf-lsr-flex-algo-bw-
>     > [e-mail];
>     > Date: 2021/07/14 01:40
>     > Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
>     > Hi,
>     > I'm the co-author of this draft and I have tried to convince the
> rest of the co-
>     > authors that encoding the new Generic Metric sub-TLV only as a
> application
>     > independent value is wrong. Unfortunately, my efforts have failed.
> As a
>     > result, although unwillingly, I have to express my opinions here and
> let the
>     > WG decide.
>     > 1) The usage of the Generic Metric sub-TLV is likely going to be
> associated
>     > with the applications, Flex-algo being the first one. Generic Metric
> sub-TLV
>     > can not be used by IGP's native calculation. So having Generic
> Metric being
>     > encoded only in legacy TLV does not make much sense.
>     > 2) TE-metric is defined as application specific attribute by RFC
> 8919/8920 and
>     > can be advertised in ASLA. The application specific value
> advertisement of TE-
>     > metric has been already proved in the field.
>     > Generic Metric is semantically very similar to TE-metric, so I see
> no reason
>     > why application specific encoding should not be supported.
>     > 3) Flex-algo specification mandates the usage of the ASLA attributes
> and all
>     > of the attributes that we are using for flex-algo so far are encoded
> in ALSA.
>     > Encoding the Generic Metric outside of ALSA violates that principle.
>     > 4) RFC 8919/8920 violation brought by Les below.
>     > thanks,
>     > Peter
>     > On 13/07/2021 17:39, Les Ginsberg (ginsberg) wrote:
>     > > Draft authors -
>     > >
>     > > I note that the new version has altered the advertisement of the
> Generic
>     > Metric sub-TLV so that it is no longer supported in the ASLA sub-TLV.
>     > > This is in direct violation of RFC 8919/8920.
>     > >
>     > > For example, https://urldefense.com/v3/__https://www.rfc-
>     > editor.org/rfc/rfc8919.html*section-6.1__;Iw!!NEt6yMaO-
>     > gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx4
>     > pA8WB0$  states:
>     > >
>     > > "New applications that future documents define to make use of the
>     > advertisements defined in this document MUST NOT make use of legacy
>     > advertisements."
>     > >
>     > > Flex-algo is a "new application" in the scope of these RFCs.
>     > >
>     > > Please correct this error.
>     > >
>     > > Thanx.
>     > >
>     > >     Les
>     > >
>     > >
>     > >> -----Original Message-----
>     > >> From: Lsr  On Behalf Of [e-mail]
>     > >> Sent: Monday, July 12, 2021 9:12 AM
>     > >> To: [e-mail]
>     > >> Cc: [e-mail]
>     > >> Subject: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-01.txt
>     > >>
>     > >>
>     > >> 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-01.txt
>     > >>     Pages           : 27
>     > >>     Date            : 2021-07-12
>     > >>
>     > >> 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-ie
>     > >> tf-lsr-flex-algo-bw-con/__;!!NEt6yMaO-
>     > gk!RDrlZO2ni4GUc8POsqsLd2DGo2Ku
>     > >> E9gbrUscAHAlbWXMsiRouKOFbEWkxyFWi9bo$
>     > >>
>     > >> There is also an htmlized version available at:
>     > >>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra
>     > >> ft-ietf-lsr-flex-algo-bw-con-01__;!!NEt6yMaO-
>     > gk!RDrlZO2ni4GUc8POsqsLd
>     > >> 2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkxwbtJYtY$
>     > >>
>     > >> A diff from the previous version is available at:
>     > >>
> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-i
>     > >> etf-lsr-flex-algo-bw-con-01__;!!NEt6yMaO-
>     > gk!RDrlZO2ni4GUc8POsqsLd2DGo
>     > >> 2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx_rX175v$
>     > >>
>     > >>
>     > >> Internet-Drafts are also available by anonymous FTP at:
>     > >>
> https://urldefense.com/v3/__ftp://ftp.ietf.org/internet-drafts/__;!!N
>     > >> Et6yMaO-
>     > gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx6
>     > >> GQqw0z$
>     > >>
>     > >>
>     > >> _______________________________________________
>     > >> Lsr mailing list
>     > >> [e-mail]
>     > >>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
>     > >> __;!!NEt6yMaO-
>     > gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOF
>     > >> bEWkx_ne0I9C$
>     > >
>     > >
>     > _______________________________________________
>     > Lsr mailing list
>     > [e-mail]
>     >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!
>     > !NEt6yMaO-
>     > gk!RDrlZO2ni4GUc8POsqsLd2DGo2KuE9gbrUscAHAlbWXMsiRouKOFbEWkx_
>     > ne0I9C$
>     _______________________________________________
>     Lsr mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/lsr
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*