Re: [auth48] AUTH48: RFC-to-be 9492 <draft-ietf-lsr-rfc8920bis-06> for your review

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

I am fine with all of the changes Acee has proposed.

  Les

From: Acee Lindem <[e-mail]>
Sent: Thursday, September 28, 2023 1:34 PM
To: Madison Church <[e-mail]>
Cc: Les Ginsberg (ginsberg) <[e-mail]>; Peter Psenak (ppsenak) <[e-mail]>; [e-mail]; [e-mail]; John E Drake <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: AUTH48: RFC-to-be 9492 <draft-ietf-lsr-rfc8920bis-06> for your review

Hi Madison,

Actually, I spoke too soon and have some changes. I removed “new” in a few places where it was redundant.
I also updated contact information and included a couple readability improvements.


*** rfc9492.txt.orig Thu Sep 28 15:47:08 2023
--- rfc9492.txt Thu Sep 28 16:27:18 2023
***************
*** 27,33 ****
     attributes, the current advertisements do not support application-
     specific values for a given attribute, nor do they support indication
     of which applications are using the advertised value for a given
!    link.  This document introduces new link attribute advertisements in
     OSPFv2 and OSPFv3 that address both of these shortcomings.

     This document obsoletes RFC 8920.
--- 27,33 ----
     attributes, the current advertisements do not support application-
     specific values for a given attribute, nor do they support indication
     of which applications are using the advertised value for a given
!    link.  This document introduces link attribute advertisements in
     OSPFv2 and OSPFv3 that address both of these shortcomings.

     This document obsoletes RFC 8920.
***************
*** 134,140 ****
     the router that is an RSVP-TE head end sees the link attribute being
     advertised for that link, it assumes RSVP-TE is enabled on that link,
     even though it is not.  If such an RSVP-TE head-end router tries to
!    set up an RSVP-TE path via that link, it will result in the path
!    setup failure.

     An additional issue arises in cases where both applications are
--- 134,140 ----
     the router that is an RSVP-TE head end sees the link attribute being
     advertised for that link, it assumes RSVP-TE is enabled on that link,
     even though it is not.  If such an RSVP-TE head-end router tries to
!    set up an RSVP-TE path via that link, it will result in a setup
!    failure for the path.

     An additional issue arises in cases where both applications are
***************
*** 263,269 ****
  5.  Advertisement of Application-Specific Values

     To allow advertisement of the application-specific values of the link
!    attribute, a new Application-Specific Link Attributes (ASLA) sub-TLV
     is defined.  The ASLA sub-TLV is a sub-TLV of the OSPFv2 Extended
     Link TLV [RFC7684] and OSPFv3 Router-Link TLV [RFC8362].

--- 263,269 ----
  5.  Advertisement of Application-Specific Values

     To allow advertisement of the application-specific values of the link
!    attribute, an Application-Specific Link Attributes (ASLA) sub-TLV
     is defined.  The ASLA sub-TLV is a sub-TLV of the OSPFv2 Extended
     Link TLV [RFC7684] and OSPFv3 Router-Link TLV [RFC8362].

***************
*** 299,305 ****
     +-                                                             -+
     |                            ...                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!    |                      Link Attribute sub-sub-TLVs              |
     +-                                                             -+
     |                            ...                                |

--- 299,305 ----
     +-                                                             -+
     |                            ...                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!    |                      Link Attribute sub-TLVs                  |
     +-                                                             -+
     |                            ...                                |

***************
*** 373,379 ****
     previously defined link attributes can be kept and reused when
     advertising them in the ASLA sub-TLV.

!    If the same attribute is advertised in more than one ASLA sub-TLVs
     with the application listed in the Application Identifier Bit Masks,
     the application SHOULD use the first instance of advertisement and
     ignore any subsequent advertisements of that attribute.
--- 373,379 ----
     previously defined link attributes can be kept and reused when
     advertising them in the ASLA sub-TLV.

!    If the same attribute is advertised in more than one ASLA sub-TLV
     with the application listed in the Application Identifier Bit Masks,
     the application SHOULD use the first instance of advertisement and
     ignore any subsequent advertisements of that attribute.
***************
*** 778,784 ****
     limited to prevent a denial-of-service (DoS) attack (distributed or
     otherwise) from overloading the OSPF control plane.

!    This document defines a new way to advertise link attributes.
     Tampering with the information defined in this document may have an
     effect on applications using it, including impacting TE, which uses
     various link attributes for its path computation.  This is similar in
--- 778,784 ----
     limited to prevent a denial-of-service (DoS) attack (distributed or
     otherwise) from overloading the OSPF control plane.

!    This document defines an improved way to advertise link attributes.
     Tampering with the information defined in this document may have an
     effect on applications using it, including impacting TE, which uses
     various link attributes for its path computation.  This is similar in
***************
*** 795,801 ****

     *  the "OSPFv3 Extended-LSA Sub-TLVs" registry

!    The new values defined in this document have been allocated using the
     IETF Review procedure as described in [RFC8126].

  14.1.  OSPFv2
--- 795,801 ----

     *  the "OSPFv3 Extended-LSA Sub-TLVs" registry

!    The values defined in this document have been allocated using the
     IETF Review procedure as described in [RFC8126].

  14.1.  OSPFv2
***************
*** 889,895 ****
     advertisements MUST be used and the specific conditions under which
     they MUST NOT be used.

!    A new subsection discussing the use of zero-length Application
     Identifier Bit Masks has been added for greater consistency with
     [RFC9479].  See Section 12.2.

--- 889,895 ----
     advertisements MUST be used and the specific conditions under which
     they MUST NOT be used.

!    A subsection discussing the use of zero-length Application
     Identifier Bit Masks has been added for greater consistency with
     [RFC9479].  See Section 12.2.

***************
*** 1026,1038 ****
     should be considered as coauthors:

     Acee Lindem
!    Cisco Systems
     United States of America
!    Email: [e-mail]<mailto:[e-mail]>


     Ketan Talaulikar
!    Arrcus, Inc.
     India
     Email: [e-mail]<mailto:[e-mail]>

--- 1026,1038 ----
     should be considered as coauthors:

     Acee Lindem
!    LabN Consulting, L.L.C.
     United States of America
!    Email: [e-mail]<mailto:[e-mail]>


     Ketan Talaulikar
!    Cisco Systems
     India
     Email: [e-mail]<mailto:[e-mail]>

Thanks,
Acee



On Sep 27, 2023, at 5:14 PM, Madison Church <[e-mail]<mailto:[e-mail]>> wrote:

Hi Les,

Thank you for your reply! We have updated the document per your responses. We have a few followup questions/comments.

1) Regarding this requested change:


1)Section 5

"Standard Application Identifier Bit Mask:  Optional set of bits,
    where each bit represents a single standard application.  Bits are
    defined in the "Link Attribute Application Identifiers" registry,
    which is defined in [RFC8919]."

The reference should be updated to be the new RFC9479.

We have updated instances of [RFC8919] to [RFC9479]. Note that RFC-to-be 9479 is in AUTH48; we will publish this document at the same time as RFC-to-be 9479.


2) Regarding this requested change:


2)Section 5

"Bit 1 (S-bit):  Segment Routing Policy.  This is data plane
      independent."

This format does not match the same text in RFC9479(to be) which is currently shown as:

" S-bit:  Set to specify SR Policy (this is data plane independent)."

My personal preference is to keep the parentheses.

We have updated the S-bit definition as you suggest above to keep the parentheses; as you note, this matches the format in RFC-to-be 9479. Would you also like to use parentheses for the F-bit definition to match RFC 9479?

Current in this document:
Bit 2 (F-bit):  LFA.  Includes all LFA types.

Current in RFC 9479:
F-bit:  Set to specify an LFA (includes all LFA types).


3) Regarding Question 7:


7) <!-- [rfced] The following expansions are defined more than once
throughout the
document. May we use the abbreviated form for the following expansions
upon
first use per Section 3.6 of RFC 7322 ("RFC Style Guide")?

Loop-Free Alternates (LFAs)
Standard Application Bit Mask (SABM)
Segment Routing (SR)
traffic engineering (TE)
User Defined Application Bit Mask (UDABM) -->

Within the definition list in Section 5, we left the expanded forms of “Standard Application Identifier Bit Mask” and “User-Defined Application Identifier Bit Mask” as is to match the field names in the figure directly above.  If you prefer to use the abbreviated forms in the definition list, please let us know. Also, would it be correct to add “field” to the following entries for clarity as shown below?

Original:
SABM Length:  Standard Application Identifier Bit Mask Length in octets.

UDABM Length:  User-Defined Application Identifier Bit Mask Length in
   octets.

Perhaps:
SABM Length:  Length of the Standard Application Identifier Bit Mask field in
   octets.

UDABM Length:  Length of the User-Defined Application Identifier Bit Mask
   field in octets.


Updated XML file:
  https://www.rfc-editor.org/authors/rfc9492.xml

Updated output files:
  https://www.rfc-editor.org/authors/rfc9492.txt
  https://www.rfc-editor.org/authors/rfc9492.pdf
  https://www.rfc-editor.org/authors/rfc9492.html

Diff file showing all changes made during AUTH48:
  https://www.rfc-editor.org/authors/rfc9492-auth48diff.html

Diff files showing all changes:
  https://www.rfc-editor.org/authors/rfc9492-diff.html
  https://www.rfc-editor.org/authors/rfc9492-rfcdiff.html (side-by-side diff)

Note that it may be necessary for you to refresh your browser to view the most recent version.

For the AUTH48 status of this document, please see:
 https://www.rfc-editor.org/auth48/rfc9492

Thank you,
RFC Editor/mc