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

[Ron Bonica <[e-mail]>]

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