Hi Karen, This has been completed:
OSPF Flexible Algorithm Definition TLV Sub-TLVs Type Description Reference Registry: https://www.iana.org/assignments/ospf-parameters/ Thank you. Best regards, David Dong IANA Services Sr. Specialist On Thu Sep 04 18:52:29 2025, kmo...@staff.rfc-editor.org wrote: > Hi IANA, > > The Document Shepherd of RFC 9350 and the authors of RFC-to-be 9843 > have agreed on changing the name of the first column in the "OSPF > Flexible Algorithm Definition TLV Sub-TLVs” registry at > "https://www.iana.org/assignments/ospf-parameters/";. Please make the > following change: > > OLD: > Bit Number > > NEW: > Type > > > Best regards, > > Karen Moore > RPC Production Center > > > > From: Acee Lindem <acee.i...@gmail.com> > > Subject: Re: AUTH48: RFC-to-be 9843 <draft-ietf-lsr-flex-algo-bw-con- > > 22> for your review > > Date: September 4, 2025 at 8:19:50 AM PDT > > To: shraddha <shrad...@juniper.net>, David Dong via RT <iana- > > iss...@iana.org> > > Cc: Karen Moore <kmo...@staff.rfc-editor.org>, "a...@cisco.com" > > <a...@cisco.com>, "tony...@tony.li" <tony...@tony.li>, Rajesh Shetty > > <mraj...@juniper.net>, Bruno Decraene <bruno.decra...@orange.com>, > > Peter Psenak <ppse...@cisco.com>, William Britto A J > > <bwill...@juniper.net>, "rfc-edi...@rfc-editor.org" <rfc-editor@rfc- > > editor.org>, "lsr-...@ietf.org" <lsr-...@ietf.org>, "lsr- > > cha...@ietf.org" <lsr-cha...@ietf.org>, > > "gunter.van_de_ve...@nokia.com" <gunter.van_de_ve...@nokia.com>, > > "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org> > > > > Hi Shraddha, > > > >> On Sep 3, 2025, at 2:43 AM, Shraddha Hegde <shrad...@juniper.net> > >> wrote: > >> > >> Hi Karen, > >> > >> > >> Thank you for the update. > >> Changes look good. > >> > >> I have one comment on IANA registry > >> > >> OSPF Sub-TLVs for Flexible Algorithm Definition Sub-TLV > >> > >> The sub-TLVs are numbered as bit number. This should have been > >> called type because > >> Its not really bit number that is being assigned here. Looks like > >> The RFC 9350 introduced this registry > >> And named it bit number. This looks incorrect to me. > >> > >> @Acee, let me know if you agree that the sub-TLVs types and not > >> really bit number. > > > > No - that should be "Type" rather than "Bit Number". > > > > https://www.iana.org/assignments/ospf-parameters/ospf- > > parameters.xhtml#flexible-algorithm-definition-tlv-sub-tlvs > > > > Copied IANA issues (iana-iss...@iana.org <mailto:iana- > > iss...@iana.org>) to fix. > > > > Thanks, > > Acee > > P.S. I guess it is your Juniper mailer that is obfuscating the URLs > > in forwarded mails? You might want to switch to a different Email > > address for IETF work as this is very annoying. > > > > > >> > >> > >> Rgds > >> Shraddha > >> > >> > >> Juniper Business Use Only > >> -----Original Message----- > >> From: Karen Moore <kmo...@staff.rfc-editor.org> > >> Sent: 30 August 2025 03:49 > >> To: Shraddha Hegde <shrad...@juniper.net>; tony...@tony.li; Rajesh M > >> <mraj...@juniper.net>; bruno.decra...@orange.com; ppse...@cisco.com; > >> William Britto A J <bwill...@juniper.net> > >> Cc: rfc-edi...@rfc-editor.org; lsr-...@ietf.org; lsr- > >> cha...@ietf.org; a...@cisco.com; gunter.van_de_ve...@nokia.com; > >> auth48archive@rfc-editor.org > >> Subject: Re: AUTH48: RFC-to-be 9843 <draft-ietf-lsr-flex-algo-bw- > >> con-22> for your review > >> > >> [External Email. Be cautious of content] > >> > >> > >> Hi Shraddha, > >> > >> Thank you providing the udpated XML file. We have updated our files > >> per your feedback; the changes are reflected in the files below > >> along with your terminology updates. Please review and let us know > >> if any further changes are needed or if you approve the document in > >> its current form. We will await approvals from each author prior to > >> moving forward in the publication process. > >> > >> 1) Note that we added the Updates tag as well as the following text > >> (as the last sentence) in the Abstract: > >> > >> Current: > >> This document updates RFC 9350. > >> > >> > >> —Files (please refresh)— > >> > >> Updated XML file: > >> https://urldefense.com/v3/__https://www.rfc- > >> editor.org/authors/rfc9843.xml__;!!NEt6yMaO- > >> gk!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4GX8rO- > >> z1$ > >> > >> Updated output files: > >> https://urldefense.com/v3/__https://www.rfc- > >> editor.org/authors/rfc9843.txt__;!!NEt6yMaO- > >> gk!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4GZS82neH$ > >> https://urldefense.com/v3/__https://www.rfc- > >> editor.org/authors/rfc9843.pdf__;!!NEt6yMaO- > >> gk!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4GdwVH- > >> mj$ > >> https://urldefense.com/v3/__https://www.rfc- > >> editor.org/authors/rfc9843.html__;!!NEt6yMaO- > >> gk!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4GYVUTcBW$ > >> > >> Diff files showing all changes made during AUTH48: > >> https://urldefense.com/v3/__https://www.rfc- > >> editor.org/authors/rfc9843-auth48diff.html__;!!NEt6yMaO- > >> gk!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4GZF4ZX0V$ > >> https://urldefense.com/v3/__https://www.rfc- > >> editor.org/authors/rfc9843-auth48rfcdiff.html__;!!NEt6yMaO- > >> gk!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4Gad0iXLO$ > >> (side by side) > >> > >> Diff files showing only the last round of changes: > >> https://urldefense.com/v3/__https://www.rfc- > >> editor.org/authors/rfc9843-lastdiff.html__;!!NEt6yMaO- > >> gk!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4GYWmHq62$ > >> https://urldefense.com/v3/__https://www.rfc- > >> editor.org/authors/rfc9843-lastrfcdiff.html__;!!NEt6yMaO- > >> gk!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4Gbq3NRaB$ > >> (side by side) > >> > >> Diff files showing all changes: > >> https://urldefense.com/v3/__https://www.rfc- > >> editor.org/authors/rfc9843-diff.html__;!!NEt6yMaO- > >> gk!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4GW9Rg2Zm$ > >> https://urldefense.com/v3/__https://www.rfc- > >> editor.org/authors/rfc9843-rfcdiff.html__;!!NEt6yMaO- > >> gk!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4Gbwjfk7S$ > >> (side by side) > >> > >> For the AUTH48 status of this document, please see: > >> https://urldefense.com/v3/__https://www.rfc- > >> editor.org/auth48/rfc9843__;!!NEt6yMaO- > >> gk!ANkX9nvlJOmcCL8zpAhFHgF9eKYXoXyj1RuXsyXLXgjXU2slTFlzM_BfRqvET6qUjNXXspYy7aIp2Ww4Gen6bexO$ > >> > >> Best regards, > >> > >> Karen Moore > >> RFC Production Center > >> > >> > >>> On Aug 29, 2025, at 7:19 AM, Shraddha Hegde <shrad...@juniper.net> > >>> wrote: > >>> > >>> Hi, > >>> > >>> Pls see inline.. > >>> > >>> > >>> Juniper Business Use Only > >>> -----Original Message----- > >>> From: Karen Moore <kmo...@staff.rfc-editor.org> > >>> Sent: 27 August 2025 05:42 > >>> To: Shraddha Hegde <shrad...@juniper.net>; William Britto A J > >>> <bwill...@juniper.net>; Rajesh M <mraj...@juniper.net>; > >>> tony...@tony.li; ppse...@cisco.com; bruno.decra...@orange.com > >>> Cc: rfc-edi...@rfc-editor.org; lsr-...@ietf.org; lsr- > >>> cha...@ietf.org; > >>> a...@cisco.com; gunter.van_de_ve...@nokia.com; > >>> auth48archive@rfc-editor.org > >>> Subject: Re: AUTH48: RFC-to-be 9843 > >>> <draft-ietf-lsr-flex-algo-bw-con-22> for your review > >>> > >>> [External Email. Be cautious of content] > >>> > >>> > >>> Hi Shraddha and William, > >>> > >>> Thank you for your replies. We have updated our files accordingly. > >>> Please review and let us know if any futher updates are needed. > >>> Note that we have some clarifications below as well an action item > >>> for the authors. > >>> > >>> 1) Please confirm if “proposes” is accurate or if “introduces” > >>> should be used in the following sentence since this document is > >>> being published as a Standards Track RFC. > >>> > >>> Current: > >>> This document proposes standard metric-types that have specific > >>> semantics and require standardization. > >>> > >>> Perhaps: > >>> This document introduces standard metric-types that have specific > >>> semantics and require standardization. > >>> > >>> <SH> "introduces" sounds better > >>> > >>> 2) This section sounds like it updates RFC 9350. Please confirm > >>> that an Updates tag is not needed on this document. > >>> > >>> Original: > >>> 6. Calculation of Flex-Algorithm paths > >>> > >>> Two new additional rules are added to the existing rules in the > >>> Flex- > >>> Algorithm calculations specified in Section 13 of [RFC9350]. > >>> > >>> 6. Check if any exclude FAEMB rule is part of the Flex-Algorithm > >>> definition. If such exclude rule exists and the link has Maximum > >>> Link Bandwidth advertised, check if the link bandwidth satisfies > >>> the FAEMB rule. If the link does not satisfy the FAEMB rule, the > >>> link MUST be pruned from the Flex-Algorithm computation. > >>> > >>> 7. Check if any exclude FAEMD rule is part of the Flex-Algorithm > >>> definition. If such exclude rule exists and the link has Min > >>> Unidirectional link delay advertised, check if the link delay > >>> satisfies the FAEMD rule. If the link does not satisfy the FAEMD > >>> rule, the link MUST be pruned from the Flex-Algorithm computation. > >>> <SH> Updates RFC 9350 tag is required. > >>> > >>> 3) Note that we updated the terminology to reflect the form on the > >>> right. Please review the updated files to ensure the updates are > >>> correct. > >>> > >>> metric type -> metric-type > >>> [Note that we left “Bandwidth metric type” as is; should it be > >>> updated as “Bandwidth metric-type” instead?] <SH> yes > >>> > >>> bandwidth metric calculation -> Bandwidth metric calculation simple > >>> mode -> Simple Mode <SH> ok > >>> > >>> — Note that no updates were made to the following terms: > >>> Bandwidth metric type > >>> Min Delay > >>> > >>> 4) We would appreciate it if the authors could update the XML file > >>> accordingly for the following terms to ensure correctness: > >>> > >>> Minimum Bandwidth value > >>> Minimum bandwidth advertised > >>> Maximum Delay constraint > >>> Maximum delay advertised > >>> <SH> attached xml with changes > >>> > >>> --Files-- > >>> Note that it may be necessary for you to refresh your browser to > >>> view the most recent version. Please review the document carefully > >>> to ensure satisfaction as we do not make changes once it has been > >>> published as an RFC. > >>> > >>> We will await approvals from each author prior to moving forward in > >>> the publication process. > >>> > >>> Updated XML file: > >>> https://urldefense.com/v3/__https://www.rfc- > >>> editor.org/authors/rfc9843 > >>> .xml__;!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G8- > >>> 8WqQI_tZ_J > >>> o5K32-9qg_w2_qNPqCHQubEPKU_brpjrIkVcW71$ > >>> > >>> Updated output files: > >>> https://urldefense.com/v3/__https://www.rfc- > >>> editor.org/authors/rfc9843 > >>> .txt__;!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G8- > >>> 8WqQI_tZ_J > >>> o5K32-9qg_w2_qNPqCHQubEPKU_brpjrKfEAk5V$ > >>> https://urldefense.com/v3/__https://www.rfc- > >>> editor.org/authors/rfc9843 > >>> .pdf__;!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G8- > >>> 8WqQI_tZ_J > >>> o5K32-9qg_w2_qNPqCHQubEPKU_brpjrJaUMdh7$ > >>> https://urldefense.com/v3/__https://www.rfc- > >>> editor.org/authors/rfc9843 > >>> .html__;!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G8- > >>> 8WqQI_tZ_ > >>> Jo5K32-9qg_w2_qNPqCHQubEPKU_brpjrAjb47PY$ > >>> > >>> Diff files showing all changes made during AUTH48: > >>> https://urldefense.com/v3/__https://www.rfc- > >>> editor.org/authors/rfc9843 > >>> -auth48diff.html__;!!NEt6yMaO- > >>> gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G > >>> 8-8WqQI_tZ_Jo5K32-9qg_w2_qNPqCHQubEPKU_brpjrF7Nghws$ > >>> https://urldefense.com/v3/__https://www.rfc- > >>> editor.org/authors/rfc9843 > >>> -auth48rfcdiff.html__;!!NEt6yMaO- > >>> gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD > >>> 36G8-8WqQI_tZ_Jo5K32-9qg_w2_qNPqCHQubEPKU_brpjrHKNknae$ (side by > >>> side) > >>> > >>> Diff files showing all changes: > >>> https://urldefense.com/v3/__https://www.rfc- > >>> editor.org/authors/rfc9843 > >>> -diff.html__;!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G8- > >>> 8WqQ > >>> I_tZ_Jo5K32-9qg_w2_qNPqCHQubEPKU_brpjrC9UzeGQ$ > >>> https://urldefense.com/v3/__https://www.rfc- > >>> editor.org/authors/rfc9843 > >>> -rfcdiff.html__;!!NEt6yMaO- > >>> gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G8-8 > >>> WqQI_tZ_Jo5K32-9qg_w2_qNPqCHQubEPKU_brpjrDXbt4qc$ (side by side) > >>> > >>> For the AUTH48 status of this document, please see: > >>> https://urldefense.com/v3/__https://www.rfc- > >>> editor.org/auth48/rfc9843_ > >>> _;!!NEt6yMaO-gk!CgXjxYdlfRtQmXNEoUOyOmobEjmyHIBQKD36G8- > >>> 8WqQI_tZ_Jo5K32 > >>> -9qg_w2_qNPqCHQubEPKU_brpjrM5qqAYY$ > >>> > >>> Best regards, > >>> > >>> Karen Moore > >>> RFC Production Center > >>> > >>> > >>>> On Aug 24, 2025, at 10:15 PM, Shraddha Hegde > >>>> <shraddha=40juniper....@dmarc.ietf.org> wrote: > >>>> > >>>> Hi, > >>>> Thank you for the work on editing the draft. > >>>> Pls see inline for responses > >>>> > >>>> > >>>> Juniper Business Use Only > >>>> -----Original Message----- > >>>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> > >>>> Sent: 19 August 2025 02:55 > >>>> To: Shraddha Hegde <shrad...@juniper.net>; William Britto A J > >>>> <bwill...@juniper.net>; Rajesh M <mraj...@juniper.net>; > >>>> bruno.decra...@orange.com; ppse...@cisco.com; tony...@tony.li > >>>> Cc: rfc-edi...@rfc-editor.org; lsr-...@ietf.org; lsr- > >>>> cha...@ietf.org; > >>>> a...@cisco.com; gunter.van_de_ve...@nokia.com; > >>>> auth48archive@rfc-editor.org > >>>> Subject: Re: AUTH48: RFC-to-be 9843 > >>>> <draft-ietf-lsr-flex-algo-bw-con-22> for your review > >>>> > >>>> [External Email. Be cautious of content] > >>>> > >>>> > >>>> Authors, > >>>> > >>>> While reviewing this document during AUTH48, please resolve (as > >>>> necessary) the following questions, which are also in the XML > >>>> file. > >>>> > >>>> 1) <!--[rfced] We removed "A J" from William Britto's name to > >>>> match use in RFC 9502. If that is not desired, please let us know. > >>>> --> > >>>> <SH> will let William confirm > >>>> > >>>> > >>>> 2) <!--[rfced] How may we clarify "and require to be > >>>> standardized"? Please let us know if option A or option B captures > >>>> in the intended meaning. > >>>> > >>>> In addition, as this document is being published as a Standards- > >>>> Track RFC, please consider whether "proposes" is accurate. > >>>> Perhaps "introduces" would work? > >>>> > >>>> Original: > >>>> This document proposes standard metric-types which have specific > >>>> semantics and require to be standardized. > >>>> > >>>> Perhaps A: > >>>> This document proposes standard metric-types that have specific > >>>> semantics and require standardization. > >>>> > >>>> Perhaps B: > >>>> This document proposes standard metric-types that have specific > >>>> semantics and requirements for standardization. > >>>> --> > >>>> <SH> I prefer A > >>>> This document proposes standard metric-types that have specific > >>>> semantics and require standardization > >>>> > >>>> 3) <!--[rfced] Should the section references be in order for ease > >>>> of reading as shown below? > >>>> > >>>> Original: > >>>> In Section 4, this document specifies a new bandwidth based metric > >>>> type to be used with Flex-Algorithm and other applications. > >>>> Section 3 defines additional Flexible Algorithm Definition (FAD) > >>>> [RFC9350] constraints that allow the network administrator to > >>>> preclude the use of low bandwidth links or high delay links. > >>>> > >>>> Section 4.1 defines... > >>>> > >>>> Perhaps: > >>>> Section 3 defines additional FAD [RFC9350] constraints that allow > >>>> the network administrator to preclude the use of low bandwidth > >>>> links > >>>> or high delay links. In Section 4, this document specifies a new > >>>> bandwidth-based metric type to be used with Flex-Algorithm and > >>>> other > >>>> applications. > >>>> > >>>> Section 4.1 defines... > >>>> --> > >>>> <SH> ok > >>>> > >>>> > >>>> 4) <!--[rfced] Should "Min Unidirectional delay metric" be > >>>> "Unidirectional Link Delay" or "Min/Max Unidirectional Link Delay" > >>>> per RFCs 8570 and 7471? > >>>> > >>>> Original: > >>>> The Traffic Engineering Default Metric is defined in [RFC5305] > >>>> and > >>>> [RFC3630] and the Min Unidirectional delay metric is defined in > >>>> [RFC8570] and [RFC7471]. > >>>> > >>>> Perhaps: > >>>> The Traffic Engineering Default Metric is defined in [RFC5305] > >>>> and > >>>> [RFC3630], and the Min/Max Unidirectional Link Delay is defined > >>>> in > >>>> [RFC8570] and [RFC7471]. > >>>> --> > >>>> <SH> It should be Unidirectional Link Delay > >>>> > >>>> New: > >>>> The Traffic Engineering Default Metric is defined in [RFC5305] > >>>> and > >>>> [RFC3630], and the Unidirectional Link Delay is defined in > >>>> [RFC8570] and [RFC7471]. > >>>> > >>>> 5) <!--[rfced] We find "TLV 22/extended link LSA/TE-LSAs" hard to > >>>> read. How may we reword this for clarity and to also include the > >>>> expansion of "LSA"? > >>>> > >>>> Also, should "generic metric sub-TLV" be singular and uppercase > >>>> for consistency as shown below? > >>>> <SH> Ok with the uppercase > >>>> > >>>> Original: > >>>> Implementations MUST support sending and receiving generic metric > >>>> sub-TLV in Application Specific Link Attributes (ASLA)encodings as > >>>> well as in the TLV 22/extended link LSA/TE-LSAs. > >>>> > >>>> Perhaps: > >>>> Implementations MUST support sending and receiving a Generic > >>>> Metric > >>>> sub-TLV in Application-Specific Link Attributes (ASLA) encodings > >>>> as > >>>> well as in TLV 22 and extended Link State Advertisements (LSAs) > >>>> and > >>>> TE-LSAs. > >>>> --> > >>>> <SH> With slight modification as below > >>>> > >>>> Implementations MUST support sending and receiving a Generic > >>>> Metric > >>>> sub-TLV in Application-Specific Link Attributes (ASLA) encodings > >>>> as > >>>> well as in TLV 22 and Extended Link Opaque Link State > >>>> Advertisements > >>>> (LSAs) [RFC7684] and TE-LSAs. > >>>> > >>>> > >>>> > >>>> 6) <!--[rfced] When referring to "TLV 22/222/23/223/141" (or "TLV > >>>> 22/23/141/222/223" > >>>> if updated), should "TLV" be plural (e.g., "TLVs > >>>> 22/222/23/223/141")? > >>>> We note that the plural form is used in the "Sub-TLVs for TLVs 22, > >>>> 23, 141, 222, and 223" registry. > >>>> > >>>> Original: > >>>> f. sub-TLV 16 (Application-Specific Link Attributes (ASLA)) of > >>>> TLV > >>>> 22/222/23/223/141 [RFC9479] > >>>> > >>>> g. TLV 25 (L2 Bundle Member Attributes) [RFC8668] Marked as > >>>> "y(s)" > >>>> (shareable among bundle members) > >>>> > >>>> ... > >>>> One example in the running text (see the document for more > >>>> instances). > >>>> > >>>> Original: > >>>> For a particular metric type, the Generic Metric sub-TLV MUST be > >>>> advertised only once for a link when advertised in TLV 22, 222, > >>>> 23, 223 and 141. > >>>> --> > >>>> <SH> Pluralisation of TLV to TLVs is ok > >>>> > >>>> > >>>> 7) <!--[rfced] Would it be correct to update "2" to "type 2" as > >>>> shown below for clarity? > >>>> > >>>> Original: > >>>> a. sub-TLV of TE Link TLV (2) of OSPF TE LSA [RFC3630]. > >>>> > >>>> b. sub-TLV of TE Link TLV (2) of OSPFv2 Inter-AS-TE-v2 LSA > >>>> [RFC5392]. > >>>> > >>>> c. sub-TLV of TE Link TLV (2) of OSPFv3 Intra-Area-TE-LSA > >>>> [RFC5329]. > >>>> > >>>> d. sub-TLV of TE Link TLV (2) of OSPFv3 Inter-AS-TE-v3 LSA > >>>> [RFC5392]. > >>>> > >>>> Perhaps: > >>>> a. sub-TLV of TE Link TLV (type 2) of OSPF TE LSA [RFC3630]. > >>>> > >>>> b. sub-TLV of TE Link TLV (type 2) of OSPFv2 Inter-AS-TE-v2 LSA > >>>> [RFC5392]. > >>>> > >>>> c. sub-TLV of TE Link TLV (type 2) of OSPFv3 Intra-Area-TE-LSA > >>>> [RFC5329]. > >>>> > >>>> d. sub-TLV of TE Link TLV (type 2) of OSPFv3 Inter-AS-TE-v3 LSA > >>>> [RFC5392]. > >>>> --> > >>>> <SH> ok > >>>> > >>>> 8) <!--[rfced] Please clarify what "this" refers to in the > >>>> following sentence. > >>>> > >>>> Original: > >>>> If the capacity of a link is constant, this can already be > >>>> achieved > >>>> through the use of administrative groups. > >>>> --> > >>>> <SH> If the capacity of a low bandwidth link is constant, > >>>> Constraining the topology to avoid those links can already be > >>>> achieved through the use of administrative groups. > >>>> > >>>> > >>>> 9) <!--[rfced] May we update this sentence for clarity as shown > >>>> below? > >>>> > >>>> Original: > >>>> Bandwidth metric is a link attribute and for the advertisement and > >>>> processing of this attribute for Flex-algorithm, MUST follow the > >>>> section 12 of [RFC9350]. > >>>> > >>>> Perhaps: > >>>> The Bandwidth Metric is a link attribute, and it MUST follow > >>>> Section > >>>> 12 of [RFC9350] for its advertisement and processing during > >>>> Flex-Algorithm calculation. > >>>> --> > >>>> <SH> ok > >>>> > >>>> 10) <!--[rfced] We updated this text to make it a complete > >>>> sentence. There are two instances in the document. Please let us > >>>> know if this is not correct. > >>>> > >>>> Original: > >>>> Staircase bandwidth threshold and associated metric values. > >>>> > >>>> Current: > >>>> Following is the staircase bandwidth threshold and associated > >>>> metric > >>>> values. > >>>> --> > >>>> <SH> ok > >>>> > >>>> 11) <!--[rfced] We note similar text in Sections 4.1.3.1, 4.1.3.2, > >>>> and 4.1.4.2. Should any of this text be in paragraph form or > >>>> bulleted form for consistency? > >>>> > >>>> Original > >>>> Section 4.1.3.1: > >>>> In case of Interface Group Mode, if > >>>> all the parallel links have been advertised with the Bandwidth > >>>> Metric, The individual link Bandwidth Metric MUST be used. If > >>>> only > >>>> some links among the parallel links have the Bandwidth Metric > >>>> advertisement, the Bandwidth Metric for such links MUST be ignored > >>>> and automatic Metric calculation MUST be used to derive link > >>>> metric. > >>>> > >>>> Section 4.1.3.2: > >>>> In case of Interface Group Mode, if all the parallel links have > >>>> been > >>>> advertised with the Bandwidth Metric, The individual link > >>>> Bandwidth > >>>> Metric MUST be used. If only some links among the parallel links > >>>> have the Bandwidth Metric advertisement, the Bandwidth Metric for > >>>> such links MUST be ignored and automatic Metric calculation MUST > >>>> be > >>>> used to derive link metric. > >>>> > >>>> Section 4.1.4.2: > >>>> In the context of Interface Group Mode, the following rules apply > >>>> to > >>>> parallel links: > >>>> > >>>> * If all parallel links have advertised the Bandwidth Metric: > >>>> > >>>> The individual link Bandwidth Metrics MUST be used for each link > >>>> during path computation. > >>>> > >>>> * If only some of the parallel links have advertised the > >>>> Bandwidth > >>>> Metric: > >>>> > >>>> - The Bandwidth Metric advertisements for those links MUST be > >>>> ignored. > >>>> > >>>> - Automatic metric calculation MUST be used to derive the link > >>>> metrics for all parallel links. > >>>> --> > >>>> <SH> Bulleted form looks more readable. Sec 4.1.3.1 and sec > >>>> 4.1.3.2 > >>>> can be modified to bulleted form > >>>> > >>>> 12) <!-- [rfced] Please review whether any of the notes in this > >>>> document should be in the <aside> element. It is defined as "a > >>>> container for content that is semantically less important or > >>>> tangential to the content that surrounds it" > >>>> (https://urldefense.com/v3/__https://authors.ietf.org/en/rfcxml- > >>>> vocabulary*aside__;Iw!!NEt6yMaO- > >>>> gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aULFhXTJk$ > >>>> ). > >>>> --> > >>>> <SH> The current form of Notes looks appropriate to me. > >>>> > >>>> > >>>> 13) <!-- [rfced] Terminology > >>>> > >>>> a) Throughout the text, the following terminology appears to be > >>>> used inconsistently. Please review these occurrences and let us > >>>> know if/how they may be made consistent. > >>>> > >>>> Bandwidth metric type vs. bandwidth metric calculation (Should > >>>> "bandwidth metric calculation" be "Bandwidth metric calculation" > >>>> to match "Bandwidth metric type"?) > >>>> > >>>> <SH> Good to use below consistently > >>>> Bandwidth metric type , Bandwidth metric calculation > >>>> > >>>> > >>>> metric-type vs. metric type > >>>> <SH> metric-type > >>>> > >>>> Minimum Bandwidth value vs. Minimum bandwidth advertised (Are > >>>> these > >>>> terms different or should "bandwidth" be uppercase for > >>>> consistency?) > >>>> <SH> When sub-TV is referred First letter should be capitalised , > >>>> when the actual value contained in the sb-TLV is referred, small > >>>> case should be used. > >>>> Exampls: > >>>> Old: > >>>> If the Maximum Link Bandwidth is lower than the Minimum Link > >>>> Bandwidth advertised in the FAEMB sub-TLV, Maximum Delay > >>>> constraint > >>>> vs. Maximum delay advertised > >>>> > >>>> New: > >>>> > >>>> If the maximum link bandwidth is lower than the minimum link > >>>> bandwidth advertised in the FAEMB sub-TLV, > >>>> > >>>> I can take a first cut on fixing this in the document. Let me know > > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
