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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Ron -

Link attributes have since Day 1 (i.e., publication of RFC 3784 (precursor to RFC 5305)) been associated with sub-TLV advertisements.
Both RFC 8919 and the Flex Algo draft are discussing attributes advertised in sub-TLVs.

IGP metric has never been advertised in a sub-TLV (or even proposed to be). Therefore it isn’t at all clear to me why you think anything regarding encoding of link attributes discussed in the above documents could or should be applied to IGP metric advertisement.

It may be true that "link attributes" could be interpreted to apply to aspects advertised in TLV 22 base encoding. This includes: Neighbor system-id and IGP metric.
Are you confused about both of these? Do you believe that ASLA/Flex documents could be interpreted to apply to Neighbor ID as well as IGP metric?
If so, then you need to explain how you reached this conclusion as I do not understand it.

   Les


> -----Original Message-----
> From: Ron Bonica <[e-mail]>
> Sent: Monday, July 26, 2021 11:31 AM
> To: Peter Psenak (ppsenak) <[e-mail]>; Acee Lindem (acee)
> <acee=[e-mail]>; Les Ginsberg (ginsberg)
> <[e-mail]>; Shraddha Hegde <[e-mail]>;
> [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: draft-ietf-lsr-flex-algo-17 (was: [Lsr] I-D Action: draft-ietf-lsr-
> flex-algo-bw-con-01.txt)
> 
> Peter,
> 
> I think that we are using the term "link attribute" differently. IMO, a link
> attribute is any attribute of a link, regardless of whether it is advertised in the
> fixed portion of a link advertisement or in a TLV.
> 
> Are you assuming otherwise? If so, why?
> 
>                                                            Ron
> 
> 
> 
> Juniper Business Use Only
> 
> -----Original Message-----
> From: Peter Psenak <[e-mail]>
> Sent: Monday, July 26, 2021 1:31 PM
> To: Ron Bonica <[e-mail]>; Acee Lindem (acee)
> <acee=[e-mail]>; Les Ginsberg (ginsberg)
> <[e-mail]>; Shraddha Hegde <[e-mail]>;
> [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: draft-ietf-lsr-flex-algo-17 (was: [Lsr] I-D Action: draft-ietf-lsr-
> flex-algo-bw-con-01.txt)
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Ron,
> 
> On 26/07/2021 18:36, Ron Bonica wrote:
> > Acee,
> >
> > We may also need to clean up an inconsistency in draft-ietf-lsr-flex-algo-17.
> Section 12 of that document says:
> >
> > "   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],
> >     unless, in the case of IS-IS, the L-Flag is set in the ASLA
> >     advertisement.  If the L-Flag is set, as defined in [RFC8919]
> >     Section 4.2 subject to the constraints discussed in Section 6 of the
> >     [[RFC8919], then legacy advertisements are to be used instead. "
> >
> > However, Flex-Algorithm calculations include the IGP metric.
> 
> 
> IGP metric is not advertised as a link attribute, it is part of the fixed portion of
> the link advertisement. So the above text is not affecting the usage if the IGP
> metric.
> 
> thanks,
> Peter
> 
> 
> >
> >
> > Ron
> >
> >
> >
> > Juniper Business Use Only
> >
> > -----Original Message-----
> > From: Acee Lindem (acee) <acee=[e-mail]>
> > Sent: Friday, July 23, 2021 10:13 AM
> > To: Ron Bonica <[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
> >
> > [External Email. Be cautious of content]
> >
> >
> > Hi Ron,
> >
> > So perhaps, generic metric is not a legacy advertisement as strictly defined.
> However, we don't want to go down the path of treating new attributes in
> the same manner as legacy attributes. It seems the discussion is progressing
> and hopefully we will have a resolution.
> >
> > Thanks,
> > Acee
> >
> > On 7/22/21, 1:28 PM, "Ron Bonica"
> <rbonica=[e-mail]> wrote:
> >
> >      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
> >
> >
> >
> >