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

[Gyan Mishra <[e-mail]>]

I see it.

Thanks Les & Peter!

Gyan

On Fri, Jul 23, 2021 at 12:34 PM Les Ginsberg (ginsberg) <[e-mail]>
wrote:

> 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 <[e-mail]>
> *Sent:* Friday, July 23, 2021 8:26 AM
> *To:* Les Ginsberg (ginsberg) <[e-mail]>
> *Cc:* Acee Lindem (acee) <[e-mail]>; Peter Psenak (ppsenak) <
> [e-mail]>; Ron Bonica <[e-mail]>; Shraddha Hegde <
> [e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> *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 <[e-mail]> 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=
> [e-mail]> 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=[e-mail]>
> > Sent: Thursday, July 22, 2021 10:28 AM
> > To: Acee Lindem (acee) <[e-mail]>; Les Ginsberg (ginsberg)
> > <[e-mail]>; Shraddha Hegde <[e-mail]>;
> > [e-mail]; Peter Psenak (ppsenak) <[e-mail]>;
> > [e-mail]
> > Cc: [e-mail]
> > 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 <[e-mail]> On Behalf Of Acee Lindem (acee)
> > Sent: Tuesday, July 20, 2021 1:21 PM
> > To: Les Ginsberg (ginsberg) <ginsberg=[e-mail]>;
> > Shraddha Hegde <[e-mail]>; [e-mail];
> > ppsenak=[e-mail]; [e-mail]
> > Cc: [e-mail]
> > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*