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 <[email protected]>
Sent: Monday, July 26, 2021 1:31 PM
To: Ron Bonica <[email protected]>; Acee Lindem (acee)
<[email protected]>; Les Ginsberg (ginsberg)
<[email protected]>; Shraddha Hegde <[email protected]>;
[email protected]; [email protected]
Cc: [email protected]
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) <[email protected]>
> Sent: Friday, July 23, 2021 10:13 AM
> To: Ron Bonica <[email protected]>; Les Ginsberg (ginsberg)
> <[email protected]>; Shraddha Hegde <[email protected]>;
> [email protected]; Peter Psenak (ppsenak) <[email protected]>;
> [email protected]
> Cc: [email protected]
> 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" <[email protected]>
> 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 <[email protected]> On Behalf Of Acee Lindem (acee)
> Sent: Tuesday, July 20, 2021 1:21 PM
> To: Les Ginsberg (ginsberg) <[email protected]>;
> Shraddha Hegde <[email protected]>; [email protected];
> [email protected]; [email protected]
> Cc: [email protected]
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
