Thank you, David! Karen Moore RFC Production Center
> On Sep 4, 2025, at 6:39 PM, David Dong via RT <[email protected]> wrote: > > 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, [email protected] 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 <[email protected]> >>> 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 <[email protected]>, David Dong via RT <iana- >>> [email protected]> >>> Cc: Karen Moore <[email protected]>, "[email protected]" >>> <[email protected]>, "[email protected]" <[email protected]>, Rajesh Shetty >>> <[email protected]>, Bruno Decraene <[email protected]>, >>> Peter Psenak <[email protected]>, William Britto A J >>> <[email protected]>, "[email protected]" <rfc-editor@rfc- >>> editor.org>, "[email protected]" <[email protected]>, "lsr- >>> [email protected]" <[email protected]>, >>> "[email protected]" <[email protected]>, >>> "[email protected]" <[email protected]> >>> >>> Hi Shraddha, >>> >>>> On Sep 3, 2025, at 2:43 AM, Shraddha Hegde <[email protected]> >>>> 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 ([email protected] <mailto:iana- >>> [email protected]>) 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 <[email protected]> >>>> Sent: 30 August 2025 03:49 >>>> To: Shraddha Hegde <[email protected]>; [email protected]; Rajesh M >>>> <[email protected]>; [email protected]; [email protected]; >>>> William Britto A J <[email protected]> >>>> Cc: [email protected]; [email protected]; lsr- >>>> [email protected]; [email protected]; [email protected]; >>>> [email protected] >>>> 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 <[email protected]> >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Pls see inline.. >>>>> >>>>> >>>>> Juniper Business Use Only >>>>> -----Original Message----- >>>>> From: Karen Moore <[email protected]> >>>>> Sent: 27 August 2025 05:42 >>>>> To: Shraddha Hegde <[email protected]>; William Britto A J >>>>> <[email protected]>; Rajesh M <[email protected]>; >>>>> [email protected]; [email protected]; [email protected] >>>>> Cc: [email protected]; [email protected]; lsr- >>>>> [email protected]; >>>>> [email protected]; [email protected]; >>>>> [email protected] >>>>> 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 >>>>>> <[email protected]> wrote: >>>>>> >>>>>> Hi, >>>>>> Thank you for the work on editing the draft. >>>>>> Pls see inline for responses >>>>>> >>>>>> >>>>>> Juniper Business Use Only >>>>>> -----Original Message----- >>>>>> From: [email protected] <[email protected]> >>>>>> Sent: 19 August 2025 02:55 >>>>>> To: Shraddha Hegde <[email protected]>; William Britto A J >>>>>> <[email protected]>; Rajesh M <[email protected]>; >>>>>> [email protected]; [email protected]; [email protected] >>>>>> Cc: [email protected]; [email protected]; lsr- >>>>>> [email protected]; >>>>>> [email protected]; [email protected]; >>>>>> [email protected] >>>>>> 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 -- [email protected] To unsubscribe send an email to [email protected]
