[Lsr] [Errata Held for Document Update] RFC2328 (7851)
The following errata report has been held for document update for RFC2328, "OSPF Version 2". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7851 -- Status: Held for Document Update Type: Technical Reported by: Acee Lindem Date Reported: 2024-03-15 Held by: Gunter Van de Velde (IESG) Section: 8.1 Original Text - Retransmissions of Link State Update packets are ALWAYS sent directly to the neighbor. On multi-access networks, this means that retransmissions should be sent to the neighbor's IP address. Corrected Text -- Retransmissions of Link State Update packets and Link State Update packets sent in response to Link State Request packets are ALWAYS sent directly to the neighbor. On multi-access networks, this means that retransmissions should be sent to the neighbor's IP address. Notes - One more place requiring clarification with respect to the Link State Update packets sent in response to Link State Request packets. -- RFC2328 (no draft string recorded) -- Title : OSPF Version 2 Publication Date: April 1998 Author(s) : J. Moy Category: INTERNET STANDARD Source : Open Shortest Path First IGP Stream : IETF Verifying Party : IESG ___ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
[Lsr] [Errata Held for Document Update] RFC2328 (7850)
The following errata report has been held for document update for RFC2328, "OSPF Version 2". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7850 -- Status: Held for Document Update Type: Technical Reported by: Alfred Lindem Date Reported: 2024-03-15 Held by: Gunter Van de Velde (IESG) Section: 10.7/A.3.5 Original Text - Section 10.7 Each LSA specified in the Link State Request packet should be located in the router's database, and copied into Link State Update packets for transmission to the neighbor. These LSAs should NOT be placed on the Link state retransmission list for the neighbor. If an LSA cannot be found in the database, something has gone wrong with the Database Exchange process, and neighbor event BadLSReq should be generated. Section A.3.5 Link State Update packets are multicast on those physical networks that support multicast/broadcast. In order to make the flooding procedure reliable, flooded LSAs are acknowledged in Link State Acknowledgment packets. If retransmission of certain LSAs is necessary, the retransmitted LSAs are always sent directly to the neighbor. For more information on the reliable flooding of LSAs, consult Section 13. Corrected Text -- Section 10.7 Each LSA specified in the Link State Request packet should be located in the router's database, and copied into Link State Update packets for transmission directly to the neighbor, i.e., unicast on all interface types except point-to-point interfaces where all OSPF packets are sent to the address AllSPFRouters. These LSAs should NOT be placed on the Link state retransmission list for the neighbor. If an LSA cannot be found in the database, something has gone wrong with the Database Exchange process, and neighbor event BadLSReq should be generated. Section A.3.5 Link State Update packets are multicast on those physical networks that support multicast/broadcast. In order to make the flooding procedure reliable, flooded LSAs are acknowledged in Link State Acknowledgment packets. If retransmission of certain LSAs is necessary, the retransmitted LSAs are always sent directly to the neighbor. For more information on the reliable flooding of LSAs, consult Section 13. Link State Update packets are also sent directly to the neighbor in response to Link State Request packets as specified in Section 10.7. Notes - Clarification that OSPF Link State Updates sent in response to OSPF Link Requests should be unicast. -- RFC2328 (no draft string recorded) -- Title : OSPF Version 2 Publication Date: April 1998 Author(s) : J. Moy Category: INTERNET STANDARD Source : Open Shortest Path First IGP Stream : IETF Verifying Party : IESG ___ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
[Lsr] [Errata Verified] RFC7684 (8104)
The following errata report has been verified for RFC7684, "OSPFv2 Prefix/Link Attribute Advertisement". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid8104 -- Status: Verified Type: Technical Reported by: Kris Michielsen Date Reported: 2024-09-16 Verified by: Gunter Van de Velde (IESG) Section: 2.1 Original Text - Route Type The type of the OSPFv2 route. If the route type is 0 (Unspecified), the information inside the OSPFv2 External Prefix TLV applies to the prefix regardless of prefix's route type. This is useful when prefix-specific attributes are advertised by an external entity that is not aware of the route type associated with the prefix. Supported types are: Corrected Text -- Route Type The type of the OSPFv2 route. If the route type is 0 (Unspecified), the information inside the OSPFv2 Extended Prefix TLV applies to the prefix regardless of prefix's route type. This is useful when prefix-specific attributes are advertised by an external entity that is not aware of the route type associated with the prefix. Supported types are: Notes - s/External Prefix/Extended Prefix/ -- RFC7684 (draft-ietf-ospf-prefix-link-attr-13) -- Title : OSPFv2 Prefix/Link Attribute Advertisement Publication Date: November 2015 Author(s) : P. Psenak, H. Gredler, R. Shakir, W. Henderickx, J. Tantsura, A. Lindem Category: PROPOSED STANDARD Source : Open Shortest Path First IGP Stream : IETF Verifying Party : IESG ___ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
[Lsr] [Technical Errata Reported] RFC7684 (8104)
The following errata report has been submitted for RFC7684, "OSPFv2 Prefix/Link Attribute Advertisement". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid8104 -- Type: Technical Reported by: Kris Michielsen Section: 2.1 Original Text - Route Type The type of the OSPFv2 route. If the route type is 0 (Unspecified), the information inside the OSPFv2 External Prefix TLV applies to the prefix regardless of prefix's route type. This is useful when prefix-specific attributes are advertised by an external entity that is not aware of the route type associated with the prefix. Supported types are: Corrected Text -- Route Type The type of the OSPFv2 route. If the route type is 0 (Unspecified), the information inside the OSPFv2 Extended Prefix TLV applies to the prefix regardless of prefix's route type. This is useful when prefix-specific attributes are advertised by an external entity that is not aware of the route type associated with the prefix. Supported types are: Notes - s/External Prefix/Extended Prefix/ Instructions: - This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -- RFC7684 (draft-ietf-ospf-prefix-link-attr-13) -- Title : OSPFv2 Prefix/Link Attribute Advertisement Publication Date: November 2015 Author(s) : P. Psenak, H. Gredler, R. Shakir, W. Henderickx, J. Tantsura, A. Lindem Category: PROPOSED STANDARD Source : Open Shortest Path First IGP Stream : IETF Verifying Party : IESG ___ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
[Lsr] [Technical Errata Reported] RFC2328 (7851)
The following errata report has been submitted for RFC2328, "OSPF Version 2". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7851 -- Type: Technical Reported by: Acee Lindem Section: 8.1 Original Text - Retransmissions of Link State Update packets are ALWAYS sent directly to the neighbor. On multi-access networks, this means that retransmissions should be sent to the neighbor's IP address. Corrected Text -- Retransmissions of Link State Update packets and Link State Update packets sent in response to Link State Request packets are ALWAYS sent directly to the neighbor. On multi-access networks, this means that retransmissions should be sent to the neighbor's IP address. Notes - One more place requiring clarification with respect to the Link State Update packets sent in response to Link State Request packets. Instructions: - This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -- RFC2328 (no draft string recorded) -- Title : OSPF Version 2 Publication Date: April 1998 Author(s) : J. Moy Category: INTERNET STANDARD Source : Open Shortest Path First IGP Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Technical Errata Reported] RFC2328 (7850)
The following errata report has been submitted for RFC2328, "OSPF Version 2". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7850 -- Type: Technical Reported by: Alfred Lindem Section: 10.7/A.3.5 Original Text - Section 10.7 Each LSA specified in the Link State Request packet should be located in the router's database, and copied into Link State Update packets for transmission to the neighbor. These LSAs should NOT be placed on the Link state retransmission list for the neighbor. If an LSA cannot be found in the database, something has gone wrong with the Database Exchange process, and neighbor event BadLSReq should be generated. Section A.3.5 Link State Update packets are multicast on those physical networks that support multicast/broadcast. In order to make the flooding procedure reliable, flooded LSAs are acknowledged in Link State Acknowledgment packets. If retransmission of certain LSAs is necessary, the retransmitted LSAs are always sent directly to the neighbor. For more information on the reliable flooding of LSAs, consult Section 13. Corrected Text -- Section 10.7 Each LSA specified in the Link State Request packet should be located in the router's database, and copied into Link State Update packets for transmission directly to the neighbor, i.e., unicast on all interface types except point-to-point interfaces where all OSPF packets are sent to the address AllSPFRouters. These LSAs should NOT be placed on the Link state retransmission list for the neighbor. If an LSA cannot be found in the database, something has gone wrong with the Database Exchange process, and neighbor event BadLSReq should be generated. Section A.3.5 Link State Update packets are multicast on those physical networks that support multicast/broadcast. In order to make the flooding procedure reliable, flooded LSAs are acknowledged in Link State Acknowledgment packets. If retransmission of certain LSAs is necessary, the retransmitted LSAs are always sent directly to the neighbor. For more information on the reliable flooding of LSAs, consult Section 13. Link State Update packets are also sent directly to the neighbor in response to Link State Request packets as specified in Section 10.7. Notes - Clarify that OSPF Link State Updates sent in response to OSPF Link Requests should be unicast. Instructions: - This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -- RFC2328 (no draft string recorded) -- Title : OSPF Version 2 Publication Date: April 1998 Author(s) : J. Moy Category: INTERNET STANDARD Source : Open Shortest Path First IGP Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Verified] RFC4576 (7765)
The following errata report has been verified for RFC4576, "Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7765 -- Status: Verified Type: Editorial Reported by: Julian Cowley Date Reported: 2024-01-15 Verified by: John Scudder (IESG) Section: 7 Original Text - [OSPFv2] Postel, J., "Suggested Telnet Protocol Changes", RFC 328, April 1972. Corrected Text -- [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. Notes - The error was caused by a missing 2 in front of the RFC number in the reference. -- RFC4576 (draft-ietf-ospf-2547-dnbit-04) -- Title : Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs) Publication Date: June 2006 Author(s) : E. Rosen, P. Psenak, P. Pillay-Esnault Category: PROPOSED STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Verified] RFC9513 (7766)
The following errata report has been verified for RFC9513, "OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7766 -- Status: Verified Type: Editorial Reported by: tom petch Date Reported: 2024-01-16 Verified by: John Scudder (IESG) Section: 6 Original Text - The AC-bit (value 0x80) in the OSPFv3 PrefixOptions field [RFC5340] is defined to advertise the anycast property: 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ |AC|EL| N|DN| P| x|LA|NU| +--+--+--+--+--+--+--+--+ Figure 2: OSPFv3 Prefix Options Field Corrected Text -- The AC-bit (value 0x80) in the OSPFv3 PrefixOptions field [RFC5340] is defined to advertise the anycast property: 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ |AC| E| N|DN| P| x|LA|NU| +--+--+--+--+--+--+--+--+ Figure 2: OSPFv3 Prefix Options Field Notes - Bit 1 is defined in RFC9089 section 6 as * Bit 0x40 in the "OSPFv3 Prefix Options (8 bits)" registry has been allocated to the E-Flag (ELC Flag). It is not the EL bit or flag. Verifier note: I added a space before the E in Tom's proposed correction, to make the diagram line up. -- RFC9513 (draft-ietf-lsr-ospfv3-srv6-extensions-15) -- Title : OSPFv3 Extensions for Segment Routing over IPv6 (SRv6) Publication Date: December 2023 Author(s) : Z. Li, Z. Hu, K. Talaulikar, Ed., P. Psenak Category: PROPOSED STANDARD Source : Link State Routing Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Editorial Errata Reported] RFC9513 (7766)
The following errata report has been submitted for RFC9513, "OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7766 -- Type: Editorial Reported by: tom petch Section: 6 Original Text - The AC-bit (value 0x80) in the OSPFv3 PrefixOptions field [RFC5340] is defined to advertise the anycast property: 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ |AC|EL| N|DN| P| x|LA|NU| +--+--+--+--+--+--+--+--+ Figure 2: OSPFv3 Prefix Options Field Corrected Text -- The AC-bit (value 0x80) in the OSPFv3 PrefixOptions field [RFC5340] is defined to advertise the anycast property: 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ |AC|E| N|DN| P| x|LA|NU| +--+--+--+--+--+--+--+--+ Figure 2: OSPFv3 Prefix Options Field Notes - Bit 1 is defined in RFC9089 section 6 as * Bit 0x40 in the "OSPFv3 Prefix Options (8 bits)" registry has been allocated to the E-Flag (ELC Flag). It is not the EL bit or flag. Instructions: - This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -- RFC9513 (draft-ietf-lsr-ospfv3-srv6-extensions-15) -- Title : OSPFv3 Extensions for Segment Routing over IPv6 (SRv6) Publication Date: December 2023 Author(s) : Z. Li, Z. Hu, K. Talaulikar, Ed., P. Psenak Category: PROPOSED STANDARD Source : Link State Routing Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Editorial Errata Reported] RFC4576 (7765)
The following errata report has been submitted for RFC4576, "Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7765 -- Type: Editorial Reported by: Julian Cowley Section: 7 Original Text - [OSPFv2] Postel, J., "Suggested Telnet Protocol Changes", RFC 328, April 1972. Corrected Text -- [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. Notes - The error was caused by a missing 2 in front of the RFC number in the reference. Instructions: - This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -- RFC4576 (draft-ietf-ospf-2547-dnbit-04) -- Title : Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs) Publication Date: June 2006 Author(s) : E. Rosen, P. Psenak, P. Pillay-Esnault Category: PROPOSED STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Rejected] RFC5340 (7649)
The following errata report has been rejected for RFC5340, "OSPF for IPv6". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7649 -- Status: Rejected Type: Technical Reported by: Owen DeLong Date Reported: 2023-09-19 Rejected by: John Scudder (IESG) Section: A.3.3 (in part) Original Text - Interface MTU The size in bytes of the largest IPv6 datagram that can be sent out the associated interface without fragmentation. The MTUs of common Internet link types can be found in Table 7-1 of [MTUDISC]. Interface MTU should be set to 0 in Database Description packets sent over virtual links. Corrected Text -- Interface MTU The size in bytes of the largest IPv6 datagram that can be sent out the associated interface without fragmentation. The MTUs of common Internet link types can be found in Table 7-1 of [MTUDISC]. Interface MTU should be set to 0 in Database Description packets sent over OSPF virtual links. This rule should not be applied to tunnel or other software interfaces. Notes - OSPF Virtual links carry only OSPF packets so MTU negotiation is not needed and this provision makes sense. For interfaces that have an actual MTU, even though they may be "virtual" interfaces, they are not "virtual links" in the intended meaning of this paragraph. As such, this change will provide clarification and remove ambiguity from the current standard. At least one popular router vendor implements this RFC as MTU = 0 sent on all GRE interfaces which results in incompatibilities with most other router platforms which expect an actual value. The router vendor points to this provision in the RFCs as justification for their implementation. It is (arguably) a legitimate, if nonsensical interpretation of the existing text. --VERIFIER NOTES-- See discussion at https://mailarchive.ietf.org/arch/msg/lsr/mrmkQt9ETTYemukBzl6K_FmgHps/ It seems as though there is not clear consensus for the proposed change or even to make a similar change; as such the normal WG process (internet draft, WG consensus) is a better way to pursue the goal. -- RFC5340 (draft-ietf-ospf-ospfv3-update-23) -- Title : OSPF for IPv6 Publication Date: July 2008 Author(s) : R. Coltun, D. Ferguson, J. Moy, A. Lindem Category: PROPOSED STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Rejected] RFC5838 (7644)
The following errata report has been rejected for RFC5838, "Support of Address Families in OSPFv3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7644 -- Status: Rejected Type: Technical Reported by: Owen DeLong Date Reported: 2023-09-17 Rejected by: John Scudder (IESG) Section: 2.7 Original Text - Interface MTU The size in octets of the largest address family specific datagram that can be sent on the associated interface without fragmentation. The MTUs of common Internet link types can be found in Table 7-1 of [MTUDISC]. The Interface MTU SHOULD be set to 0 in Database Description packets sent over virtual links. Corrected Text -- Interface MTU The size in octets of the largest address family specific datagram that can be sent on the associated interface without fragmentation. The MTUs of common Internet link types can be found in Table 7-1 of [MTUDISC]. The Interface MTU SHOULD be set to 0 in Database Description packets sent over (OSPF3) virtual links. This recommendation MUST NOT be applied to tunnel and other virtual or software interfaces which carry traffic other than OSPF protocol packets. Notes - Currently, the language is ambiguous and at least one vendor has implemented OSPF3 sending an MTU of zero on GRE interfaces (and possibly others such as IPIP, IPSEC, etc., as I have not tested these). I believe that the intent of the RFC is to refer strictly to OSPF virtual-links which carry only OSPF protocol data and therefore have no meaningful MTU. When this is mistakenly applied to other forms of "virtual" interfaces such as tunnels, the results can be quite harmful. As such, I think that clarification is in order, since the vendor in question is unrepentant and claims their current implementation to be compliant with the RFC. --VERIFIER NOTES-- See discussion at https://mailarchive.ietf.org/arch/msg/lsr/wXdOtU9H2vIoA1xs10xZ4oh8bwU/ -- RFC5838 (draft-ietf-ospf-af-alt-10) -- Title : Support of Address Families in OSPFv3 Publication Date: April 2010 Author(s) : A. Lindem, Ed., S. Mirtorabi, A. Roy, M. Barnes, R. Aggarwal Category: PROPOSED STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Verified] RFC2328 (7756)
The following errata report has been verified for RFC2328, "OSPF Version 2". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7756 -- Status: Verified Type: Editorial Reported by: Lokesh Venkata Kumar Chakka Date Reported: 2024-01-11 Verified by: John Scudder (IESG) Section: A.4.5 Original Text - AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by AS boundary routers, and describe destinations external to the AS. For details concerning the construction of AS-external-LSAs, see Section 12.4.3. Corrected Text -- AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by AS boundary routers, and describe destinations external to the AS. For details concerning the construction of AS-external-LSAs, see Section 12.4.4. Notes - Incorrect references. Construction of AS-external-LSAs explained in Section 12.4.4. Not in 12.4. (See also https://mailarchive.ietf.org/arch/msg/lsr/OiOvEPM2W-Mwd_QgbmJASg8bDOI/) -- RFC2328 (no draft string recorded) -- Title : OSPF Version 2 Publication Date: April 1998 Author(s) : J. Moy Category: INTERNET STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Rejected] RFC2328 (7757)
The following errata report has been rejected for RFC2328, "OSPF Version 2". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7757 -- Status: Rejected Type: Technical Reported by: Lokesh Venkata Kumar Chakka Date Reported: 2024-01-11 Rejected by: John Scudder (IESG) Section: A.4.5 Original Text - Forwarding address Data traffic for the advertised destination will be forwarded to this address. If the Forwarding address is set to 0.0.0.0, data traffic will be forwarded instead to the LSA's originator (i.e., the responsible AS boundary router). Corrected Text -- Forwarding address Data traffic for the advertised destination will be forwarded to this address. If the Forwarding address is set to a Router ID address value other than 0.0.0.0, data traffic will be forwarded to that Router instead to the LSA's originator (i.e., the responsible AS boundary router). Notes - Data traffic destined to the network indicated by Link State ID will be routed to that Router ID mentioned in forwarding address. If forwarding address is set to 0.0.0.0, it will be forwarded to LSA Originator itself. --VERIFIER NOTES-- See https://mailarchive.ietf.org/arch/msg/lsr/_Xa4tym_roMmxFioFbrF3WRkKcM/ -- RFC2328 (no draft string recorded) -- Title : OSPF Version 2 Publication Date: April 1998 Author(s) : J. Moy Category: INTERNET STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Technical Errata Reported] RFC2328 (7757)
The following errata report has been submitted for RFC2328, "OSPF Version 2". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7757 -- Type: Technical Reported by: Lokesh Venkata Kumar Chakka Section: A.4.5 Original Text - Forwarding address Data traffic for the advertised destination will be forwarded to this address. If the Forwarding address is set to 0.0.0.0, data traffic will be forwarded instead to the LSA's originator (i.e., the responsible AS boundary router). Corrected Text -- Forwarding address Data traffic for the advertised destination will be forwarded to this address. If the Forwarding address is set to a Router ID address value other than 0.0.0.0, data traffic will be forwarded to that Router instead to the LSA's originator (i.e., the responsible AS boundary router). Notes - Data traffic destined to the network indicated by Link State ID will be routed to that Router ID mentioned in forwarding address. If forwarding address is set to 0.0.0.0, it will be forwarded to LSA Originator itself. Instructions: - This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -- RFC2328 (no draft string recorded) -- Title : OSPF Version 2 Publication Date: April 1998 Author(s) : J. Moy Category: INTERNET STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Editorial Errata Reported] RFC2328 (7756)
The following errata report has been submitted for RFC2328, "OSPF Version 2". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7756 -- Type: Editorial Reported by: Lokesh Venkata Kumar Chakka Section: A.4.5 Original Text - AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by AS boundary routers, and describe destinations external to the AS. For details concerning the construction of AS-external-LSAs, see Section 12.4.3 Corrected Text -- AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by AS boundary routers, and describe destinations external to the AS. For details concerning the construction of AS-external-LSAs, see Section 12.4.4 Notes - Incorrect references. Construction of AS-external-LSAs explained in Section 12.4.4. Not in 12.4.3 Instructions: - This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -- RFC2328 (no draft string recorded) -- Title : OSPF Version 2 Publication Date: April 1998 Author(s) : J. Moy Category: INTERNET STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Verified] RFC8667 (7722)
The following errata report has been verified for RFC8667, "IS-IS Extensions for Segment Routing". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7722 -- Status: Verified Type: Editorial Reported by: John Scudder Date Reported: 2023-12-07 Verified by: Andrew Alston (IESG) Section: 2.1.1.1 Original Text - 2.1.1.1. V-Flag and L-Flag Corrected Text -- 2.1.1.1. V-Flag, L-Flag, and the SID/Index/Label Field Notes - Since the SID/Index/Label field is defined in this subsection, it's misleading for the title to mention only the flags and is a disservice to readers using the document as a reference. This is also discussed in https://mailarchive.ietf.org/arch/msg/lsr/56_LEEZvHDHrnkC98f7BtpOkkY0/ where Acee also suggests a broader clarification. The narrowly-scoped change reflected in this erratum seems sufficient to fix the problem I encountered; in my view, it doesn't preclude an additional erratum for some of the other matters that were mentioned by Acee if there's support for that as well. Thanks to Tony Li for suggesting the wording. I agree this helps clarify the text which could easily have otherwise been misread - hence the verification of the errata -- RFC8667 (draft-ietf-isis-segment-routing-extensions-25) -- Title : IS-IS Extensions for Segment Routing Publication Date: December 2019 Author(s) : S. Previdi, Ed., L. Ginsberg, Ed., C. Filsfils, A. Bashandy, H. Gredler, B. Decraene Category: PROPOSED STANDARD Source : Link State Routing Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Editorial Errata Reported] RFC8667 (7722)
The following errata report has been submitted for RFC8667, "IS-IS Extensions for Segment Routing". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7722 -- Type: Editorial Reported by: John Scudder Section: 2.1.1.1 Original Text - 2.1.1.1. V-Flag and L-Flag Corrected Text -- 2.1.1.1. V-Flag, L-Flag, and the SID/Index/Label Field Notes - Since the SID/Index/Label field is defined in this subsection, it's misleading for the title to mention only the flags and is a disservice to readers using the document as a reference. This is also discussed in https://mailarchive.ietf.org/arch/msg/lsr/56_LEEZvHDHrnkC98f7BtpOkkY0/ where Acee also suggests a broader clarification. The narrowly-scoped change reflected in this erratum seems sufficient to fix the problem I encountered; in my view, it doesn't preclude an additional erratum for some of the other matters that were mentioned by Acee if there's support for that as well. Thanks to Tony Li for suggesting the wording. Instructions: - This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -- RFC8667 (draft-ietf-isis-segment-routing-extensions-25) -- Title : IS-IS Extensions for Segment Routing Publication Date: December 2019 Author(s) : S. Previdi, Ed., L. Ginsberg, Ed., C. Filsfils, A. Bashandy, H. Gredler, B. Decraene Category: PROPOSED STANDARD Source : Link State Routing Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Technical Errata Reported] RFC5340 (7649)
The following errata report has been submitted for RFC5340, "OSPF for IPv6". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7649 -- Type: Technical Reported by: Owen DeLong Section: A.3.3 (in part) Original Text - Interface MTU The size in bytes of the largest IPv6 datagram that can be sent out the associated interface without fragmentation. The MTUs of common Internet link types can be found in Table 7-1 of [MTUDISC]. Interface MTU should be set to 0 in Database Description packets sent over virtual links. Corrected Text -- Interface MTU The size in bytes of the largest IPv6 datagram that can be sent out the associated interface without fragmentation. The MTUs of common Internet link types can be found in Table 7-1 of [MTUDISC]. Interface MTU should be set to 0 in Database Description packets sent over OSPF virtual links. This rule should not be applied to tunnel or other software interfaces. Notes - OSPF Virtual links carry only OSPF packets so MTU negotiation is not needed and this provision makes sense. For interfaces that have an actual MTU, even though they may be "virtual" interfaces, they are not "virtual links" in the intended meaning of this paragraph. As such, this change will provide clarification and remove ambiguity from the current standard. At least one popular router vendor implements this RFC as MTU = 0 sent on all GRE interfaces which results in incompatibilities with most other router platforms which expect an actual value. The router vendor points to this provision in the RFCs as justification for their implementation. It is (arguably) a legitimate, if nonsensical interpretation of the existing text. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC5340 (draft-ietf-ospf-ospfv3-update-23) -- Title : OSPF for IPv6 Publication Date: July 2008 Author(s) : R. Coltun, D. Ferguson, J. Moy, A. Lindem Category: PROPOSED STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Technical Errata Reported] RFC5838 (7644)
The following errata report has been submitted for RFC5838, "Support of Address Families in OSPFv3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7644 -- Type: Technical Reported by: Owen DeLong Section: 2.7 Original Text - Interface MTU The size in octets of the largest address family specific datagram that can be sent on the associated interface without fragmentation. The MTUs of common Internet link types can be found in Table 7-1 of [MTUDISC]. The Interface MTU SHOULD be set to 0 in Database Description packets sent over virtual links. Corrected Text -- Interface MTU The size in octets of the largest address family specific datagram that can be sent on the associated interface without fragmentation. The MTUs of common Internet link types can be found in Table 7-1 of [MTUDISC]. The Interface MTU SHOULD be set to 0 in Database Description packets sent over (OSPF3) virtual links. This recommendation MUST NOT be applied to tunnel and other virtual or software interfaces which carry traffic other than OSPF protocol packets. Notes - Currently, the language is ambiguous and at least one vendor has implemented OSPF3 sending an MTU of zero on GRE interfaces (and possibly others such as IPIP, IPSEC, etc., as I have not tested these). I believe that the intent of the RFC is to refer strictly to OSPF virtual-links which carry only OSPF protocol data and therefore have no meaningful MTU. When this is mistakenly applied to other forms of "virtual" interfaces such as tunnels, the results can be quite harmful. As such, I think that clarification is in order, since the vendor in question is unrepentant and claims their current implementation to be compliant with the RFC. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC5838 (draft-ietf-ospf-af-alt-10) -- Title : Support of Address Families in OSPFv3 Publication Date: April 2010 Author(s) : A. Lindem, Ed., S. Mirtorabi, A. Roy, M. Barnes, R. Aggarwal Category: PROPOSED STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Verified] RFC7770 (7524)
The following errata report has been verified for RFC7770, "Extensions to OSPF for Advertising Optional Router Capabilities". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7524 -- Status: Verified Type: Editorial Reported by: James N Guichard Date Reported: 2023-05-24 Verified by: John Scudder (IESG) Section: 5.4 Original Text - o The values are defined in Section 2.6. All Router Informational Capability TLV additions are to be assigned through IETF Review [IANA-GUIDE]. Corrected Text -- o The values are defined in Section 2.5. All Router Informational Capability Bit additions are to be assigned through IETF Review [IANA-GUIDE]. Notes - Router Informational Capabilities bits are defined in section 2.5 of the document and NOT section 2.6, and they are bits, not TLVs. See also https://mailarchive.ietf.org/arch/msg/lsr/pc0-mos28aQ7D59ijCBDWLctAXE/ -- RFC7770 (draft-ietf-ospf-rfc4970bis-07) -- Title : Extensions to OSPF for Advertising Optional Router Capabilities Publication Date: February 2016 Author(s) : A. Lindem, Ed., N. Shen, JP. Vasseur, R. Aggarwal, S. Shaffer Category: PROPOSED STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Editorial Errata Reported] RFC7770 (7524)
The following errata report has been submitted for RFC7770, "Extensions to OSPF for Advertising Optional Router Capabilities". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7524 -- Type: Editorial Reported by: James N Guichard Section: 5.4 Original Text - o The values are defined in Section 2.6. All Router Informational Capability TLV additions are to be assigned through IETF Review [IANA-GUIDE]. Corrected Text -- o The values are defined in Section 2.5. All Router Informational Capability TLV additions are to be assigned through IETF Review [IANA-GUIDE]. Notes - Router Informational Capabilities bits are defined in section 2.5 of the document and NOT section 2.6. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC7770 (draft-ietf-ospf-rfc4970bis-07) -- Title : Extensions to OSPF for Advertising Optional Router Capabilities Publication Date: February 2016 Author(s) : A. Lindem, Ed., N. Shen, JP. Vasseur, R. Aggarwal, S. Shaffer Category: PROPOSED STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Technical Errata Reported] RFC7474 (7485)
The following errata report has been submitted for RFC7474, "Security Extension for OSPFv2 When Using Manual Key Management". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7485 -- Type: Technical Reported by: Rajeev Kumar Surroach Section: 7474 Original Text - 7474 Corrected Text -- 7474 Notes - Solve the issue Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC7474 (draft-ietf-ospf-security-extension-manual-keying-11) -- Title : Security Extension for OSPFv2 When Using Manual Key Management Publication Date: April 2015 Author(s) : M. Bhatia, S. Hartman, D. Zhang, A. Lindem, Ed. Category: PROPOSED STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Technical Errata Reported] RFC7471 (7482)
The following errata report has been submitted for RFC7471, "OSPF Traffic Engineering (TE) Metric Extensions". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7482 -- Type: Technical Reported by: Rajeev Kumar Surroach Section: 7471 Original Text - 7471 Corrected Text -- 7471 Notes - Solve the issue Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC7471 (draft-ietf-ospf-te-metric-extensions-11) -- Title : OSPF Traffic Engineering (TE) Metric Extensions Publication Date: March 2015 Author(s) : S. Giacalone, D. Ward, J. Drake, A. Atlas, S. Previdi Category: PROPOSED STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Verified] RFC9350 (7406)
The following errata report has been verified for RFC9350, "IGP Flexible Algorithm". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7406 -- Status: Verified Type: Editorial Reported by: Barry Friedman Date Reported: 2023-03-28 Verified by: John Scudder (IESG) Section: 5.1 Original Text - The IS-IS FAD sub-TLV MAY be advertised in a Label Switched Path (LSP) of any number. Corrected Text -- The IS-IS FAD sub-TLV MAY be advertised in a Link State PDU (LSP) of any number. Notes - I assume LSP is meant to refer to the PDU carrying the FAD, not a Label Switched Path. -- RFC9350 (draft-ietf-lsr-flex-algo-26) -- Title : IGP Flexible Algorithm Publication Date: February 2023 Author(s) : P. Psenak, Ed., S. Hegde, C. Filsfils, K. Talaulikar, A. Gulko Category: PROPOSED STANDARD Source : Link State Routing Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Editorial Errata Reported] RFC9350 (7406)
The following errata report has been submitted for RFC9350, "IGP Flexible Algorithm". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7406 -- Type: Editorial Reported by: Barry Friedman Section: 5.1 Original Text - The IS-IS FAD sub-TLV MAY be advertised in a Label Switched Path (LSP) of any number. Corrected Text -- The IS-IS FAD sub-TLV MAY be advertised in a Link State PDU (LSP) of any number. Notes - I assume LSP is meant to refer to the PDU carrying the FAD, not a Label Switched Path. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC9350 (draft-ietf-lsr-flex-algo-26) -- Title : IGP Flexible Algorithm Publication Date: February 2023 Author(s) : P. Psenak, Ed., S. Hegde, C. Filsfils, K. Talaulikar, A. Gulko Category: PROPOSED STANDARD Source : Link State Routing Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Held for Document Update] RFC9350 (7376)
The following errata report has been held for document update for RFC9350, "IGP Flexible Algorithm". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7376 -- Status: Held for Document Update Type: Editorial Reported by: Nikolai Malykh Date Reported: 2023-03-04 Held by: John Scudder (IESG) Section: 6 Original Text - One of the limitations of IS-IS [ISO10589] is that the length of a TLV/sub-TLV is limited to a maximum of 255 octets. For the FAD sub- TLV, there are a number of sub-sub-TLVs (defined below) that are supported. For a given Flex-Algorithm, it is possible that the total number of octets required to completely define a FAD exceeds the maximum length supported by a single FAD sub-TLV. In such cases, the FAD MAY be split into multiple such sub-TLVs, and the content of the multiple FAD sub-TLVs are combined to provide a complete FAD for the Flex-Algorithm. In such a case, the fixed portion of the FAD (see Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex- Algorithm from a given IS. Corrected Text -- One of the limitations of IS-IS [ISO10589] is that the length of a TLV/sub-TLV is limited to a maximum of 255 octets. For the FAD sub- TLV, there are a number of sub-sub-TLVs (defined below) that are supported. For a given Flex-Algorithm, it is possible that the total number of octets required to completely define a FAD exceeds the maximum length supported by a single FAD sub-TLV. In such cases, the FAD MAY be split into multiple such sub-TLVs, and the content of the multiple FAD sub-TLVs are combined to provide a complete FAD for the Flex-Algorithm. In such a case, the fixed portion of the FAD (see Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex- Algorithm from a given IS (Intermediate System). Notes - Although "IS" is listed in https://www.rfc-editor.org/materials/abbrev.expansion.txt as well-known, this evidently confused at least one reader, so it seems worth expanding on first use. See also https://mailarchive.ietf.org/arch/msg/lsr/LICQJ8U3cBAY9Z1LHMfAI4v7xRg/ -- RFC9350 (draft-ietf-lsr-flex-algo-26) -- Title : IGP Flexible Algorithm Publication Date: February 2023 Author(s) : P. Psenak, Ed., S. Hegde, C. Filsfils, K. Talaulikar, A. Gulko Category: PROPOSED STANDARD Source : Link State Routing Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Editorial Errata Reported] RFC9350 (7376)
The following errata report has been submitted for RFC9350, "IGP Flexible Algorithm". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7376 -- Type: Editorial Reported by: Nikolai Malykh Section: 6 Original Text - One of the limitations of IS-IS [ISO10589] is that the length of a TLV/sub-TLV is limited to a maximum of 255 octets. For the FAD sub- TLV, there are a number of sub-sub-TLVs (defined below) that are supported. For a given Flex-Algorithm, it is possible that the total number of octets required to completely define a FAD exceeds the maximum length supported by a single FAD sub-TLV. In such cases, the FAD MAY be split into multiple such sub-TLVs, and the content of the multiple FAD sub-TLVs are combined to provide a complete FAD for the Flex-Algorithm. In such a case, the fixed portion of the FAD (see Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex- Algorithm from a given IS. Corrected Text -- One of the limitations of IS-IS [ISO10589] is that the length of a TLV/sub-TLV is limited to a maximum of 255 octets. For the FAD sub- TLV, there are a number of sub-sub-TLVs (defined below) that are supported. For a given Flex-Algorithm, it is possible that the total number of octets required to completely define a FAD exceeds the maximum length supported by a single FAD sub-TLV. In such cases, the FAD MAY be split into multiple such sub-TLVs, and the content of the multiple FAD sub-TLVs are combined to provide a complete FAD for the Flex-Algorithm. In such a case, the fixed portion of the FAD (see Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex- Algorithm from a given IS-IS. Notes - Incorrect name of protocol (IS instead IS-IS). Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC9350 (draft-ietf-lsr-flex-algo-26) -- Title : IGP Flexible Algorithm Publication Date: February 2023 Author(s) : P. Psenak, Ed., S. Hegde, C. Filsfils, K. Talaulikar, A. Gulko Category: PROPOSED STANDARD Source : Link State Routing Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Technical Errata Reported] RFC9346 (7348)
The following errata report has been submitted for RFC9346, "IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7348 -- Type: Technical Reported by: a Section: glober Original Text - i Corrected Text -- i Notes - i Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC9346 (draft-ietf-lsr-isis-rfc5316bis-07) -- Title : IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering Publication Date: February 2023 Author(s) : M. Chen, L. Ginsberg, S. Previdi, D. Xiaodong Category: PROPOSED STANDARD Source : Link State Routing Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Verified] RFC3277 (7127)
The following errata report has been verified for RFC3277, "Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7127 -- Status: Verified Type: Editorial Reported by: John Scudder Date Reported: 2022-09-12 Verified by: Alvaro Retana (IESG) Section: 2 Original Text - As such, it is recommended that each time a router establishes an adjacency, it will update its LSP and flood it immediately, even before beginning database synchronization. This will allow for the Overload bit setting to propagate immediately, and remove the potential for an older version of the reloaded routers LSP to be used. Corrected Text -- As such, it is recommended that each time a router establishes an adjacency, it will update its LSP and flood it immediately, even before beginning database synchronization. This will allow for the Overload bit setting to propagate immediately, and remove the potential for an older version of the reloaded router's LSP to be used. Notes - "reloaded router's" should be possessive singular. -- RFC3277 (draft-ietf-isis-transient-02) -- Title : Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance Publication Date: April 2002 Author(s) : D. McPherson Category: INFORMATIONAL Source : IS-IS for IP Internets Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Editorial Errata Reported] RFC3277 (7127)
The following errata report has been submitted for RFC3277, "Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7127 -- Type: Editorial Reported by: John Scudder Section: 2 Original Text - As such, it is recommended that each time a router establishes an adjacency, it will update its LSP and flood it immediately, even before beginning database synchronization. This will allow for the Overload bit setting to propagate immediately, and remove the potential for an older version of the reloaded routers LSP to be used. Corrected Text -- As such, it is recommended that each time a router establishes an adjacency, it will update its LSP and flood it immediately, even before beginning database synchronization. This will allow for the Overload bit setting to propagate immediately, and remove the potential for an older version of the reloaded router's LSP to be used. Notes - "reloaded router's" should be possessive singular. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC3277 (draft-ietf-isis-transient-02) -- Title : Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance Publication Date: April 2002 Author(s) : D. McPherson Category: INFORMATIONAL Source : IS-IS for IP Internets Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Verified] RFC2328 (7112)
The following errata report has been verified for RFC2328, "OSPF Version 2". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7112 -- Status: Verified Type: Editorial Reported by: Renato Westphal Date Reported: 2022-09-01 Verified by: John Scudder (IESG) Section: 10.2 Original Text - NegotiationDone The Master/Slave relationship has been negotiated, and DD sequence numbers have been exchanged. This signals the start of the sending/receiving of Database Description packets. For more information on the generation of this event, consult Section 10.8. Corrected Text -- NegotiationDone The Master/Slave relationship has been negotiated, and DD sequence numbers have been exchanged. This signals the start of the sending/receiving of Database Description packets. For more information on the generation of this event, consult Section 10.6. Notes - The generation of the NegotiationDone event is specified in Section 10.6 (not Section 10.8). (Also discussed at https://mailarchive.ietf.org/arch/msg/lsr/NZMWapi62sJuExnBZFBBMdW169k/) -- RFC2328 (no draft string recorded) -- Title : OSPF Version 2 Publication Date: April 1998 Author(s) : J. Moy Category: INTERNET STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Editorial Errata Reported] RFC2328 (7112)
The following errata report has been submitted for RFC2328, "OSPF Version 2". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7112 -- Type: Editorial Reported by: Renato Westphal Section: 10.2 Original Text - NegotiationDone The Master/Slave relationship has been negotiated, and DD sequence numbers have been exchanged. This signals the start of the sending/receiving of Database Description packets. For more information on the generation of this event, consult Section 10.8. Corrected Text -- NegotiationDone The Master/Slave relationship has been negotiated, and DD sequence numbers have been exchanged. This signals the start of the sending/receiving of Database Description packets. For more information on the generation of this event, consult Section 10.6. Notes - The generation of the NegotiationDone event is specified in Section 10.6 (not Section 10.8). Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC2328 (no draft string recorded) -- Title : OSPF Version 2 Publication Date: April 1998 Author(s) : J. Moy Category: INTERNET STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Editorial Errata Reported] RFC6823 (7084)
The following errata report has been submitted for RFC6823, "Advertising Generic Information in IS-IS". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7084 -- Type: Editorial Reported by: Keep Section: Global Original Text - Rosen, E., "Exterior Gateway Protocol," IEN-209, Bolt > Beranek and Newman Inc., August 1982. Corrected Text -- Rosen, E., "Exterior Gateway Protocol," IEN-209, Bolt > Beranek and Newman Inc., August 1982, not issued Notes - > RFC823 references IEN-209, which was not issued, and won't be > (https://www.rfc-editor.org/ien/scanned/ien209.pdf). I encourage discussion > of whether it should reference RFC827 instead. > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC6823 (draft-ietf-isis-genapp-04) > -- > Title : Advertising Generic Information in IS-IS > Publication Date: December 2012 > Author(s) : L. Ginsberg, S. Previdi, M. Shand > Category: PROPOSED STANDARD > Source : IS-IS for IP Internets > Area: Routing > Stream : IETF > Verifying Party : IESG Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC6823 (draft-ietf-isis-genapp-04) -- Title : Advertising Generic Information in IS-IS Publication Date: December 2012 Author(s) : L. Ginsberg, S. Previdi, M. Shand Category: PROPOSED STANDARD Source : IS-IS for IP Internets Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Technical Errata Reported] RFC6823 (6995)
The following errata report has been submitted for RFC6823, "Advertising Generic Information in IS-IS". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6995 -- Type: Technical Reported by: keep Section: global Original Text - [10] Rosen, E., "Exterior Gateway Protocol," IEN-209, Bolt Beranek and Newman Inc., August 1982. Corrected Text -- [10] Rosen, E., "Exterior Gateway Protocol," IEN-209, Bolt Beranek and Newman Inc., August 1982, not issued Notes - RFC823 references IEN-209, which was not issued, and won't be (https://www.rfc-editor.org/ien/scanned/ien209.pdf). I encourage discussion of whether it should reference RFC827 instead. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC6823 (draft-ietf-isis-genapp-04) -- Title : Advertising Generic Information in IS-IS Publication Date: December 2012 Author(s) : L. Ginsberg, S. Previdi, M. Shand Category: PROPOSED STANDARD Source : IS-IS for IP Internets Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Rejected] RFC8920 (6631)
The following errata report has been rejected for RFC8920, "OSPF Application-Specific Link Attributes". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6631 -- Status: Rejected Type: Technical Reported by: Les Ginsberg Date Reported: 2021-07-05 Rejected by: John Scudder (IESG) Section: 5 Original Text - OLD If link attributes are advertised with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications, then any standard application and/or any user-defined application is permitted to use that set of link attributes. If support for a new application is introduced on any node in a network in the presence of such advertisements, these advertisements are permitted to be used by the new application. If this is not what is intended, then existing advertisements MUST be readvertised with an explicit set of applications specified before a new application is introduced. An application-specific advertisement (Application Identifier Bit Mask with a matching Application Identifier Bit set) for an attribute MUST always be preferred over the advertisement of the same attribute with the zero-length Application Identifier Bit Masks for both standard applications and user-defined applications on the same link. Corrected Text -- NEW Link attributes MAY be advertised associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications. Such link attribute advertisements MUST be used by standard applications and/or user defined applications when no link attribute advertisements with a non-zero-length Application Identifier Bit Mask and a matching Application Identifier Bit set are present for a given link. Otherwise, such link attribute advertisements MUST NOT be used. Notes - RFC 8920 defines advertising link attributes with zero length Standard Application Bit Mask (SABM) and zero length User Defined ApplicationBit Mask (UDABM) as a means of advertising link attributes that can be used by any application. However, the text uses the word "permitted", suggesting that the use of such advertisements is "optional". Such an interpretation could lead to interoperability issues and is not what was intended. The replacement text below makes explicit the specific conditions when such advertisements MUST be used and the specific conditions under which they MUST NOT be used. --VERIFIER NOTES-- It would be more appropriate to pursue this as an update or bis RFC. See discussion at https://mailarchive.ietf.org/arch/msg/lsr/Ux9x1Zz9R8p7aZ_7iu1jjU-88E0/ and https://mailarchive.ietf.org/arch/msg/lsr/_15rAwElfpGLDRxqjUuUJHiGdrQ/ -- RFC8920 (draft-ietf-ospf-te-link-attr-reuse-16) -- Title : OSPF Application-Specific Link Attributes Publication Date: October 2020 Author(s) : P. Psenak, Ed., L. Ginsberg, W. Henderickx, J. Tantsura, J. Drake Category: PROPOSED STANDARD Source : Link State Routing Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Rejected] RFC8919 (6630)
The following errata report has been rejected for RFC8919, "IS-IS Application-Specific Link Attributes". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6630 -- Status: Rejected Type: Technical Reported by: Les Ginsberg Date Reported: 2021-07-05 Rejected by: John Scudder (IESG) Section: GLOBAL Original Text - Section 4.2: OLD If the SABM or UDABM Length in the Application Identifier Bit Mask is greater than 8, the entire sub-TLV MUST be ignored. (Later in Section 4.2) OLD If link attributes are advertised associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications, then any standard application and/or any user-defined application is permitted to use that set of link attributes so long as there is not another set of attributes advertised on that same link that is associated with a non-zero-length Application Identifier Bit Mask with a matching Application Identifier Bit set. Section 6.2 OLD Link attribute advertisements associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications are usable by any application, subject to the restrictions specified in Section 4.2. If support for a new application is introduced on any node in a network in the presence of such advertisements, these advertisements are permitted to be used by the new application. If this is not what is intended, then existing advertisements MUST be readvertised with an explicit set of applications specified before a new application is introduced. Corrected Text -- Section 4.2 NEW If the SABM or UDABM Length in the Application Identifier Bit Mask is greater than 8, the entire sub-TLV MUST be ignored. When SABM or UDABM Length is non-zero and the L-flag is NOT set, all applications specified in the bit mask MUST use the link attribute advertisements in the sub-TLV. (Later in Section 4.2) NEW Link attributes MAY be advertised associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications. Such link attribute advertisements MUST be used by standard applications and/or user defined applications when no link attribute advertisements with a non-zero-length Application Identifier Bit Mask and a matching Application Identifier Bit set are present for a given link. Otherwise, such link attribute advertisements MUST NOT be used. Section 6.2 NEW Link attributes MAY be advertised associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications. Such link attribute advertisements MUST be used by standard applications and/or user defined applications when no link attribute advertisements with a non-zero-length Application Identifier Bit Mask and a matching Application Identifier Bit set are present for a given link. Otherwise, such link attribute advertisements MUST NOT be used. Notes - RFC 8919 defines advertising link attributes with zero length Standard Application Bit Mask (SABM) and zero length User Defined ApplicationBit Mask (UDABM) as a means of advertising link attributes that can be used by any application. However, the text uses the word "permitted", suggesting that the use of such advertisements is "optional". Such an interpretation could lead to interoperability issues and is not what was intended. The replacement text below makes explicit the specific conditions when such advertisements MUST be used and the specific conditions under which they MUST NOT be used. --VERIFIER NOTES-- It would be more appropriate to pursue this as an update or bis RFC, see discussion at https://mailarchive.ietf.org/arch/msg/lsr/_15rAwElfpGLDRxqjUuUJHiGdrQ/ -- RFC8919 (draft-ietf-isis-te-app-19) -- Title : IS-IS Application-Specific Link Attributes Publication Date: October 2020 Author(s) : L. Ginsberg, P. Psenak, S. Previdi, W. Henderickx, J. Drake Category: PROPOSED STANDARD Source : Link State Routing Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Verified] RFC8668 (6957)
The following errata report has been verified for RFC8668, "Advertising Layer 2 Bundle Member Link Attributes in IS-IS". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6957 -- Status: Verified Type: Editorial Reported by: Praveen Kumar Date Reported: 2022-05-09 Verified by: John Scudder (IESG) Section: 5 Original Text - The name of the IANA registry for Sub-TLVs for TLVs 22, 23, 141, 222, and 223 has been changed to include sub-TLV 25. Corrected Text -- The name of the IANA registry for Sub-TLVs for TLVs 22, 23, 141, 222, and 223 has been changed to include TLV 25. Notes - 25 is top-level TLV. By mistake, it is written as sub-TLV. (See also https://mailarchive.ietf.org/arch/msg/lsr/LvcOMxMuJW40ThHJeV3nOjl-0HY/) -- RFC8668 (draft-ietf-isis-l2bundles-07) -- Title : Advertising Layer 2 Bundle Member Link Attributes in IS-IS Publication Date: December 2019 Author(s) : L. Ginsberg, Ed., A. Bashandy, C. Filsfils, M. Nanduri, E. Aries Category: PROPOSED STANDARD Source : IS-IS for IP Internets Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Verified] RFC2328 (6679)
The following errata report has been verified for RFC2328, "OSPF Version 2". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6679 -- Status: Verified Type: Editorial Reported by: Nikolai Malykh Date Reported: 2021-09-07 Verified by: John Scudder (IESG) Section: .4 Original Text - The area border routers RT3, RT4, RT7, RT10 and RT11 condense the routing information of their attached non-backbone areas for distribution via the backbone; these are the dashed stubs that appear in Figure 8. Remember that the third area has been configured to condense Networks N9-N11 and Host H1 into a single route. This yields a single dashed line for networks N9-N11 and Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary routers; their externally derived information also appears on the graph in Figure 8 as stubs. Corrected Text -- The area border routers RT3, RT4, RT7, RT10 and RT11 condense the routing information of their attached non-backbone areas for distribution via the backbone; these are the dashed stubs that appear in Figure 6. Remember that the third area has been configured to condense Networks N9-N11 and Host H1 into a single route. This yields a single dashed line for networks N9-N11 and Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary routers; their externally derived information also appears on the graph in Figure 8 as stubs. Notes - Incorrect figure number (8 instead 6). -- RFC2328 (no draft string recorded) -- Title : OSPF Version 2 Publication Date: April 1998 Author(s) : J. Moy Category: INTERNET STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Editorial Errata Reported] RFC8668 (6957)
The following errata report has been submitted for RFC8668, "Advertising Layer 2 Bundle Member Link Attributes in IS-IS". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6957 -- Type: Editorial Reported by: Praveen Kumar Section: 5 Original Text - The name of the IANA registry for Sub-TLVs for TLVs 22, 23, 141, 222, and 223 has been changed to include sub-TLV 25. Corrected Text -- The name of the IANA registry for Sub-TLVs for TLVs 22, 23, 141, 222, and 223 has been changed to include TLV 25. Notes - 25 is top-level TLV. By mistake, it is written as sub-TLV. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC8668 (draft-ietf-isis-l2bundles-07) -- Title : Advertising Layer 2 Bundle Member Link Attributes in IS-IS Publication Date: December 2019 Author(s) : L. Ginsberg, Ed., A. Bashandy, C. Filsfils, M. Nanduri, E. Aries Category: PROPOSED STANDARD Source : IS-IS for IP Internets Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Technical Errata Reported] RFC5311 (6903)
The following errata report has been submitted for RFC5311, "Simplified Extension of Link State PDU (LSP) Space for IS-IS". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6903 -- Type: Technical Reported by: Jesus Alvarado Section: 1305 Original Text - In the 1.2 there are admin mirrors if you know your box’s and 1305 is the being of 8 Corrected Text -- Well I should of had an office but the crowd that follows me won’t let me be they find people to open doors and more. Like the Biltmore in Portland Oregon I had to many. Notes - The text I am not trying to throw through here . Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC5311 (draft-ietf-isis-wg-extlsp-05) -- Title : Simplified Extension of Link State PDU (LSP) Space for IS-IS Publication Date: February 2009 Author(s) : D. McPherson, Ed., L. Ginsberg, S. Previdi, M. Shand Category: PROPOSED STANDARD Source : IS-IS for IP Internets Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Verified] RFC8665 (6838)
The following errata report has been verified for RFC8665, "OSPF Extensions for Segment Routing". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6838 -- Status: Verified Type: Editorial Reported by: Praveen Kumar Date Reported: 2022-02-05 Verified by: John Scudder (IESG) Section: 6.1 Original Text - B-Flag: Backup Flag. If set, the Adj-SID refers to an adjacency that is eligible for protection (e.g., using IP Fast Reroute or MPLS-FRR (MPLS-Fast Reroute) as described in Section 2.1 of [RFC8402]. Corrected Text -- B-Flag: Backup Flag. If set, the Adj-SID refers to an adjacency that is eligible for protection (e.g., using IP Fast Reroute or MPLS-FRR (MPLS-Fast Reroute) as described in Section 3.4 of [RFC8402]. Notes - I don't see any section 2.1 in RFC 8402. Reference of section 2.1 of RFC 8402 seems incorrect. It should be section 3.4 as per my understanding. Kindly fix it if possible. -- RFC8665 (draft-ietf-ospf-segment-routing-extensions-27) -- Title : OSPF Extensions for Segment Routing Publication Date: December 2019 Author(s) : P. Psenak, Ed., S. Previdi, Ed., C. Filsfils, H. Gredler, R. Shakir, W. Henderickx, J. Tantsura Category: PROPOSED STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Editorial Errata Reported] RFC8665 (6838)
The following errata report has been submitted for RFC8665, "OSPF Extensions for Segment Routing". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6838 -- Type: Editorial Reported by: Praveen Kumar Section: 6.1 Original Text - B-Flag: Backup Flag. If set, the Adj-SID refers to an adjacency that is eligible for protection (e.g., using IP Fast Reroute or MPLS-FRR (MPLS-Fast Reroute) as described in Section 2.1 of [RFC8402]. Corrected Text -- B-Flag: Backup Flag. If set, the Adj-SID refers to an adjacency that is eligible for protection (e.g., using IP Fast Reroute or MPLS-FRR (MPLS-Fast Reroute) as described in Section 3.4 of [RFC8402]. Notes - I don't see any section 2.1 in RFC 8402. Reference of section 2.1 of RFC 8402 seems incorrect. It should be section 3.4 as per my understanding. Kindly fix it if possible. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC8665 (draft-ietf-ospf-segment-routing-extensions-27) -- Title : OSPF Extensions for Segment Routing Publication Date: December 2019 Author(s) : P. Psenak, Ed., S. Previdi, Ed., C. Filsfils, H. Gredler, R. Shakir, W. Henderickx, J. Tantsura Category: PROPOSED STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Editorial Errata Reported] RFC2328 (6679)
The following errata report has been submitted for RFC2328, "OSPF Version 2". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6679 -- Type: Editorial Reported by: Nikolai Malykh Section: 3.4 Original Text - The area border routers RT3, RT4, RT7, RT10 and RT11 condense the routing information of their attached non-backbone areas for distribution via the backbone; these are the dashed stubs that appear in Figure 8. Remember that the third area has been configured to condense Networks N9-N11 and Host H1 into a single route. This yields a single dashed line for networks N9-N11 and Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary routers; their externally derived information also appears on the graph in Figure 8 as stubs. Corrected Text -- The area border routers RT3, RT4, RT7, RT10 and RT11 condense the routing information of their attached non-backbone areas for distribution via the backbone; these are the dashed stubs that appear in Figure 6. Remember that the third area has been configured to condense Networks N9-N11 and Host H1 into a single route. This yields a single dashed line for networks N9-N11 and Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary routers; their externally derived information also appears on the graph in Figure 8 as stubs. Notes - Incorrect figure number (8 instead 6). Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC2328 (no draft string recorded) -- Title : OSPF Version 2 Publication Date: April 1998 Author(s) : J. Moy Category: INTERNET STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Technical Errata Reported] RFC8920 (6631)
The following errata report has been submitted for RFC8920, "OSPF Application-Specific Link Attributes". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6631 -- Type: Technical Reported by: Les Ginsberg Section: 5 Original Text - OLD If link attributes are advertised with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications, then any standard application and/or any user-defined application is permitted to use that set of link attributes. If support for a new application is introduced on any node in a network in the presence of such advertisements, these advertisements are permitted to be used by the new application. If this is not what is intended, then existing advertisements MUST be readvertised with an explicit set of applications specified before a new application is introduced. An application-specific advertisement (Application Identifier Bit Mask with a matching Application Identifier Bit set) for an attribute MUST always be preferred over the advertisement of the same attribute with the zero-length Application Identifier Bit Masks for both standard applications and user-defined applications on the same link. Corrected Text -- NEW Link attributes MAY be advertised associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications. Such link attribute advertisements MUST be used by standard applications and/or user defined applications when no link attribute advertisements with a non-zero-length Application Identifier Bit Mask and a matching Application Identifier Bit set are present for a given link. Otherwise, such link attribute advertisements MUST NOT be used. Notes - RFC 8920 defines advertising link attributes with zero length Standard Application Bit Mask (SABM) and zero length User Defined ApplicationBit Mask (UDABM) as a means of advertising link attributes that can be used by any application. However, the text uses the word "permitted", suggesting that the use of such advertisements is "optional". Such an interpretation could lead to interoperability issues and is not what was intended. The replacement text below makes explicit the specific conditions when such advertisements MUST be used and the specific conditions under which they MUST NOT be used. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC8920 (draft-ietf-ospf-te-link-attr-reuse-16) -- Title : OSPF Application-Specific Link Attributes Publication Date: October 2020 Author(s) : P. Psenak, Ed., L. Ginsberg, W. Henderickx, J. Tantsura, J. Drake Category: PROPOSED STANDARD Source : Link State Routing Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Technical Errata Reported] RFC8919 (6630)
The following errata report has been submitted for RFC8919, "IS-IS Application-Specific Link Attributes". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6630 -- Type: Technical Reported by: Les Ginsberg Section: GLOBAL Original Text - Section 4.2: OLD If the SABM or UDABM Length in the Application Identifier Bit Mask is greater than 8, the entire sub-TLV MUST be ignored. (Later in Section 4.2) OLD If link attributes are advertised associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications, then any standard application and/or any user-defined application is permitted to use that set of link attributes so long as there is not another set of attributes advertised on that same link that is associated with a non-zero-length Application Identifier Bit Mask with a matching Application Identifier Bit set. Section 6.2 OLD Link attribute advertisements associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications are usable by any application, subject to the restrictions specified in Section 4.2. If support for a new application is introduced on any node in a network in the presence of such advertisements, these advertisements are permitted to be used by the new application. If this is not what is intended, then existing advertisements MUST be readvertised with an explicit set of applications specified before a new application is introduced. Corrected Text -- Section 4.2 NEW If the SABM or UDABM Length in the Application Identifier Bit Mask is greater than 8, the entire sub-TLV MUST be ignored. When SABM or UDABM Length is non-zero and the L-flag is NOT set, all applications specified in the bit mask MUST use the link attribute advertisements in the sub-TLV. (Later in Section 4.2) NEW Link attributes MAY be advertised associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications. Such link attribute advertisements MUST be used by standard applications and/or user defined applications when no link attribute advertisements with a non-zero-length Application Identifier Bit Mask and a matching Application Identifier Bit set are present for a given link. Otherwise, such link attribute advertisements MUST NOT be used. Section 6.2 NEW Link attributes MAY be advertised associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications. Such link attribute advertisements MUST be used by standard applications and/or user defined applications when no link attribute advertisements with a non-zero-length Application Identifier Bit Mask and a matching Application Identifier Bit set are present for a given link. Otherwise, such link attribute advertisements MUST NOT be used. Notes - RFC 8919 defines advertising link attributes with zero length Standard Application Bit Mask (SABM) and zero length User Defined ApplicationBit Mask (UDABM) as a means of advertising link attributes that can be used by any application. However, the text uses the word "permitted", suggesting that the use of such advertisements is "optional". Such an interpretation could lead to interoperability issues and is not what was intended. The replacement text below makes explicit the specific conditions when such advertisements MUST be used and the specific conditions under which they MUST NOT be used. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC8919 (draft-ietf-isis-te-app-19) -- Title : IS-IS Application-Specific Link Attributes Publication Date: October 2020 Author(s) : L. Ginsberg, P. Psenak, S. Previdi, W. Henderickx, J. Drake Category: PROPOSED STANDARD Source : Link State Routing Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Rejected] RFC5185 (6506)
The following errata report has been rejected for RFC5185, "OSPF Multi-Area Adjacency". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6506 -- Status: Rejected Type: Technical Reported by: Ketan Talaulikar Date Reported: 2021-04-02 Rejected by: John Scudder (IESG) Section: 2.7 Original Text - Multi-area adjacencies are announced as point-to-point links. Once the router's multi-area adjacency reaches the FULL state, it will be added as a link type 1 to the Router Link State Advertisement (LSA) with: Link ID = Remote's Router ID Link Data = Neighbor's IP Address or IfIndex (if the underlying interface is unnumbered). Unlike numbered point-to-point links, no type 3 link is advertised for multi-area adjacencies. Corrected Text -- Multi-area adjacencies are announced as point-to-point links. Once the router's multi-area adjacency reaches the FULL state, it will be added as a link type 1 to the Router Link State Advertisement (LSA) with: Link ID = Remote's Router ID Link Data = Router interface's IP Address or IfIndex (if the underlying interface is unnumbered). Unlike numbered point-to-point links, no type 3 link is advertised for multi-area adjacencies. Notes - The encoding of Link Data as specified in RFC5185 is not consistent with the base OSPF specification in RFC2328. This has resulted in different behaviors in deployed implementations where some follow RFC2328 (i.e. the corrected text) while others follow the Original text of RFC5185 leading to interop issues. More importantly, for implementations of RFC5185, it is not possible to determine the Neighbor's interface IfIndex unless some additional mechanisms (that have not been specified or referenced by RFC5185) are implemented - viz. RFC8510. This topic has been discussed in the LSR WG recently and this errata is being raised to track this issue : https://mailarchive.ietf.org/arch/msg/lsr/iL85WkrqhI17wUrxd-WozMQvKtE/ --VERIFIER NOTES-- As discussed here (https://mailarchive.ietf.org/arch/msg/lsr/9IAkRCbZN39loWcwKjtNWfUW_qA/) this would be a technical change vs. the WG consensus when the document was progressed, and should be rejected (see https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/ #7). The appropriate way to pursue this looks to be an update or bis. -- RFC5185 (draft-ietf-ospf-multi-area-adj-09) -- Title : OSPF Multi-Area Adjacency Publication Date: May 2008 Author(s) : S. Mirtorabi, P. Psenak, A. Lindem, Ed., A. Oswal Category: PROPOSED STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Editorial Errata Reported] RFC9013 (6576)
The following errata report has been submitted for RFC9013, "OSPF Advertisement of Tunnel Encapsulations". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6576 -- Type: Editorial Reported by: Sabrina Tanamal Section: 7.2 Original Text - | 3 | Endpoint | RFC 9013| Corrected Text -- | 3 | Tunnel Egress Endpoint| RFC 9013 | Notes - The description of value 3 should have been updated to match updates throughout the text. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC9013 (draft-ietf-ospf-encapsulation-cap-09) -- Title : OSPF Advertisement of Tunnel Encapsulations Publication Date: April 2021 Author(s) : X. Xu, Ed., B. Decraene, Ed., R. Raszuk, L. Contreras, L. Jalil Category: PROPOSED STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Technical Errata Reported] RFC5185 (6506)
The following errata report has been submitted for RFC5185, "OSPF Multi-Area Adjacency". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6506 -- Type: Technical Reported by: Ketan Talaulikar Section: 2.7 Original Text - Multi-area adjacencies are announced as point-to-point links. Once the router's multi-area adjacency reaches the FULL state, it will be added as a link type 1 to the Router Link State Advertisement (LSA) with: Link ID = Remote's Router ID Link Data = Neighbor's IP Address or IfIndex (if the underlying interface is unnumbered). Unlike numbered point-to-point links, no type 3 link is advertised for multi-area adjacencies. Corrected Text -- Multi-area adjacencies are announced as point-to-point links. Once the router's multi-area adjacency reaches the FULL state, it will be added as a link type 1 to the Router Link State Advertisement (LSA) with: Link ID = Remote's Router ID Link Data = Router interface's IP Address or IfIndex (if the underlying interface is unnumbered). Unlike numbered point-to-point links, no type 3 link is advertised for multi-area adjacencies. Notes - The encoding of Link Data as specified in RFC5185 is not consistent with the base OSPF specification in RFC2328. This has resulted in different behaviors in deployed implementations where some follow RFC2328 (i.e. the corrected text) while others follow the Original text of RFC5185 leading to interop issues. More importantly, for implementations of RFC5185, it is not possible to determine the Neighbor's interface IfIndex unless some additional mechanisms (that have not been specified or referenced by RFC5185) are implemented - viz. RFC8510. This topic has been discussed in the LSR WG recently and this errata is being raised to track this issue : https://mailarchive.ietf.org/arch/msg/lsr/iL85WkrqhI17wUrxd-WozMQvKtE/ Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC5185 (draft-ietf-ospf-multi-area-adj-09) -- Title : OSPF Multi-Area Adjacency Publication Date: May 2008 Author(s) : S. Mirtorabi, P. Psenak, A. Lindem, Ed., A. Oswal Category: PROPOSED STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Rejected] RFC2328 (5956)
The following errata report has been rejected for RFC2328, "OSPF Version 2". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid5956 -- Status: Rejected Type: Technical Reported by: Marcelo Bustani Date Reported: 2020-01-08 Rejected by: Alvaro Retana (IESG) Section: 12.4.1 Original Text - Router-LSAs If the state of the interface is Loopback, add a Type 3 link (stub network) as long as this is not an interface to an unnumbered point-to-point network. The Link ID should be set to the IP interface address, the Link Data set to the mask 0x (indicating a host route), and the cost set to 0. === 12.4.1.4. Describing Point-to-MultiPoint interfaces For operational Point-to-MultiPoint interfaces, one or more link descriptions are added to the router-LSA as follows: o A single Type 3 link (stub network) is added with Link ID set to the router's own IP interface address, Link Data set to the mask 0x (indicating a host route), and cost set to 0. = C.3 Router interface parameters Interface output cost The cost of sending a packet on the interface, expressed in the link state metric. This is advertised as the link cost for this interface in the router's router-LSA. The interface output cost must always be greater than 0. Corrected Text -- "cost set to 0" to at least "greater than 0" Notes - The section 12.4.1 and 12.4.1.4 are inconsistent with the appendix c.3. These both section we find the cost to stub networks have to be set to 0, but in appendix c.3 we see that the interfaces must have greater than 0. --VERIFIER NOTES-- A discussion on the WG list (lsr) resulted a consensus of no change needed. https://mailarchive.ietf.org/arch/msg/lsr/FFiqi15XPunSwOV5BO1pl4o5xYY/ -- RFC2328 (no draft string recorded) -- Title : OSPF Version 2 Publication Date: April 1998 Author(s) : J. Moy Category: INTERNET STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Technical Errata Reported] RFC2328 (5956)
The following errata report has been submitted for RFC2328, "OSPF Version 2". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid5956 -- Type: Technical Reported by: Marcelo Bustani Section: 12.4.1 Original Text - Router-LSAs If the state of the interface is Loopback, add a Type 3 link (stub network) as long as this is not an interface to an unnumbered point-to-point network. The Link ID should be set to the IP interface address, the Link Data set to the mask 0x (indicating a host route), and the cost set to 0. === 12.4.1.4. Describing Point-to-MultiPoint interfaces For operational Point-to-MultiPoint interfaces, one or more link descriptions are added to the router-LSA as follows: o A single Type 3 link (stub network) is added with Link ID set to the router's own IP interface address, Link Data set to the mask 0x (indicating a host route), and cost set to 0. = C.3 Router interface parameters Interface output cost The cost of sending a packet on the interface, expressed in the link state metric. This is advertised as the link cost for this interface in the router's router-LSA. The interface output cost must always be greater than 0. Corrected Text -- "cost set to 0" to at least "greater than 0" Notes - The section 12.4.1 and 12.4.1.4 are inconsistent with the appendix c.3. These both section we find the cost to stub networks have to be set to 0, but in appendix c.3 we see that the interfaces must have greater than 0. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC2328 (no draft string recorded) -- Title : OSPF Version 2 Publication Date: April 1998 Author(s) : J. Moy Category: INTERNET STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Rejected] RFC2328 (5684)
The following errata report has been rejected for RFC2328, "OSPF Version 2". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid5684 -- Status: Rejected Type: Editorial Reported by: jonathan natale Date Reported: 2019-04-04 Rejected by: Alvaro Retana (IESG) Section: 9.4 Original Text - These two alternatives (~=">=1 BDRs" vs. ~="no BDRs") seem (to me at least, maybe I missed the point) to have the same outcome (~="highest becomes BDR")--please clarify it: If one or more of these routers have declared themselves Backup Designated Router[alternative1] (i.e., they are currently listing themselves as Backup Designated Router, but not as Designated Router, in their Hello Packets) the one having highest Router Priority is declared to be Backup Designated Router. In case of a tie, the one having the highest Router ID is chosen. If no routers have declared themselves Backup Designated Router[alternative2], Moy Standards Track[Page 75] RFC 2328 OSPF Version 2 April 1998 choose the router having highest Router Priority, (again excluding those routers who have declared themselves Designated Router), and again use the Router ID to break ties. Corrected Text -- TBD Notes - It is unclear to me if a BDR should get preempted (I know the BDR should not). --VERIFIER NOTES-- The confusion was cleared on the WG list. -- RFC2328 (no draft string recorded) -- Title : OSPF Version 2 Publication Date: April 1998 Author(s) : J. Moy Category: INTERNET STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Editorial Errata Reported] RFC2328 (5684)
The following errata report has been submitted for RFC2328, "OSPF Version 2". -- You may review the report below and at: http://www.rfc-editor.org/errata/eid5684 -- Type: Editorial Reported by: jonathan natale Section: 9.4 Original Text - These two alternatives (~=">=1 BDRs" vs. ~="no BDRs") seem (to me at least, maybe I missed the point) to have the same outcome (~="highest becomes BDR")--please clarify it: If one or more of these routers have declared themselves Backup Designated Router[alternative1] (i.e., they are currently listing themselves as Backup Designated Router, but not as Designated Router, in their Hello Packets) the one having highest Router Priority is declared to be Backup Designated Router. In case of a tie, the one having the highest Router ID is chosen. If no routers have declared themselves Backup Designated Router[alternative2], Moy Standards Track[Page 75] RFC 2328 OSPF Version 2 April 1998 choose the router having highest Router Priority, (again excluding those routers who have declared themselves Designated Router), and again use the Router ID to break ties. Corrected Text -- TBD Notes - It is unclear to me if a BDR should get preempted (I know the BDR should not). Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC2328 (no draft string recorded) -- Title : OSPF Version 2 Publication Date: April 1998 Author(s) : J. Moy Category: INTERNET STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Rejected] RFC2328 (5611)
The following errata report has been rejected for RFC2328, "OSPF Version 2". -- You may review the report below and at: http://www.rfc-editor.org/errata/eid5611 -- Status: Rejected Type: Technical Reported by: Anil Chaitanya Mandru Date Reported: 2019-01-22 Rejected by: Alvaro Retana (IESG) Section: 16.1 (4) Original Text - In this case, the current routing table entry should be overwritten if and only if the newly found path is just as short and the current routing table entry's Link State Origin has a smaller Link State ID than the newly added vertex' LSA. Corrected Text -- In this case, if the newly found path is just as short, then both the paths should be added to the routing table. Notes - If the newly found path is just as short then both the paths should be considered for ECMP. Why should the smaller Link State ID path overwrite the current one even if the paths are equi distant? --VERIFIER NOTES-- See WG discussion here: https://mailarchive.ietf.org/arch/msg/lsr/ACVzdktoiFbIcMyQck1RCGn50es >From Acee Lindem: "This is the case where the transit network vertex >corresponding to a network-LSA is newly added to the current intra-area graph >and an intra-area route corresponding to the SPF in progress already exists. >This implies that there was another network-LSA. So, either the network >corresponding to the subnet is partitioned or there is a network configuration >error with the same subnet configured for multiple multi-access networks. In >either case, I don't really see the benefit of an ECMP route. In fact, it >could make trouble-shooting the problem more difficult. " Note also that the proposed text would result in a modification of the process to calculate the routing table, not just a correction. A change like that should be discussed in the WG/mailing list instead. -- RFC2328 (no draft string recorded) -- Title : OSPF Version 2 Publication Date: April 1998 Author(s) : J. Moy Category: INTERNET STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Technical Errata Reported] RFC2328 (5611)
The following errata report has been submitted for RFC2328, "OSPF Version 2". -- You may review the report below and at: http://www.rfc-editor.org/errata/eid5611 -- Type: Technical Reported by: Anil Chaitanya Mandru Section: 16.1 (4) Original Text - In this case, the current routing table entry should be overwritten if and only if the newly found path is just as short and the current routing table entry's Link State Origin has a smaller Link State ID than the newly added vertex' LSA. Corrected Text -- In this case, if the newly found path is just as short, then both the paths should be added to the routing table. Notes - If the newly found path is just as short then both the paths should be considered for ECMP. Why should the smaller Link State ID path overwrite the current one even if the paths are equi distant? Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC2328 (no draft string recorded) -- Title : OSPF Version 2 Publication Date: April 1998 Author(s) : J. Moy Category: INTERNET STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Held for Document Update] RFC7810 (5486)
The following errata report has been held for document update for RFC7810, "IS-IS Traffic Engineering (TE) Metric Extensions". -- You may review the report below and at: http://www.rfc-editor.org/errata/eid5486 -- Status: Held for Document Update Type: Editorial Reported by: Teresa Date Reported: 2018-08-31 Held by: Alvaro Retana (IESG) Section: 4.6 Original Text - Available Bandwidth: This field carries the available bandwidth on a link, forwarding adjacency, or bundled link in IEEE floating-point format with units of bytes per second. For a link or forwarding adjacency, available bandwidth is defined to be residual bandwidth (see Section 4.5) minus the measured bandwidth used for the actual forwarding of non-RSVP-TE label switched path packets. For a bundled link, available bandwidth is defined to be the sum of the component link available bandwidths minus the measured bandwidth used for the actual forwarding of non-RSVP-TE label switched path packets. For a bundled link, available bandwidth is defined to be the sum of the component link available bandwidths. Corrected Text -- Available Bandwidth: This field carries the available bandwidth on a link, forwarding adjacency, or bundled link in IEEE floating-point format with units of bytes per second. For a link or forwarding adjacency, available bandwidth is defined to be residual bandwidth (see Section 4.5) minus the measured bandwidth used for the actual forwarding of non-RSVP-TE label switched path packets. For a bundled link, available bandwidth is defined to be the sum of the component link (residual) bandwidths minus the measured bandwidth used for the actual forwarding of non-RSVP-TE label switched path packets.For a bundled link, available bandwidth is defined to be the sum of the component link available bandwidths. Notes - Two sentences to explain 'available bandwidth' on a bundled link, but one says "sum of component available bandwidth minus xxx", the other says "sum of component available bandwidth", is conflicting. need to change the first sentence to 'sum of component residual bandwidth minus xxx' -- RFC7810 (draft-ietf-isis-te-metric-extensions-11) -- Title : IS-IS Traffic Engineering (TE) Metric Extensions Publication Date: May 2016 Author(s) : S. Previdi, Ed., S. Giacalone, D. Ward, J. Drake, Q. Wu Category: PROPOSED STANDARD Source : IS-IS for IP Internets Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Technical Errata Reported] RFC4167 (5367)
The following errata report has been submitted for RFC4167, "Graceful OSPF Restart Implementation Report". -- You may review the report below and at: http://pubtest.rfc-editor.org/errata/eid5367 -- Type: Technical Reported by: Priyanka Section: GLOBAL Original Text - OT Corrected Text -- CT Notes - Notes Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC4167 (draft-ietf-ospf-graceful-impl-report-05) -- Title : Graceful OSPF Restart Implementation Report Publication Date: October 2005 Author(s) : A. Lindem Category: INFORMATIONAL Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Editorial Errata Reported] RFC7810 (5486)
The following errata report has been submitted for RFC7810, "IS-IS Traffic Engineering (TE) Metric Extensions". -- You may review the report below and at: http://www.rfc-editor.org/errata/eid5486 -- Type: Editorial Reported by: Teresa Section: 4.6 Original Text - Available Bandwidth: This field carries the available bandwidth on a link, forwarding adjacency, or bundled link in IEEE floating-point format with units of bytes per second. For a link or forwarding adjacency, available bandwidth is defined to be residual bandwidth (see Section 4.5) minus the measured bandwidth used for the actual forwarding of non-RSVP-TE label switched path packets. For a bundled link, available bandwidth is defined to be the sum of the component link available bandwidths minus the measured bandwidth used for the actual forwarding of non-RSVP-TE label switched path packets. For a bundled link, available bandwidth is defined to be the sum of the component link available bandwidths. Corrected Text -- Available Bandwidth: This field carries the available bandwidth on a link, forwarding adjacency, or bundled link in IEEE floating-point format with units of bytes per second. For a link or forwarding adjacency, available bandwidth is defined to be residual bandwidth (see Section 4.5) minus the measured bandwidth used for the actual forwarding of non-RSVP-TE label switched path packets. For a bundled link, available bandwidth is defined to be the sum of the component link (residual) bandwidths minus the measured bandwidth used for the actual forwarding of non-RSVP-TE label switched path packets.For a bundled link, available bandwidth is defined to be the sum of the component link available bandwidths. Notes - Two sentences to explain 'available bandwidth' on a bundled link, but one says "sum of component available bandwidth minus xxx", the other says "sum of component available bandwidth", is conflicting. need to change the first sentence to 'sum of component residual bandwidth minus xxx' Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC7810 (draft-ietf-isis-te-metric-extensions-11) -- Title : IS-IS Traffic Engineering (TE) Metric Extensions Publication Date: May 2016 Author(s) : S. Previdi, Ed., S. Giacalone, D. Ward, J. Drake, Q. Wu Category: PROPOSED STANDARD Source : IS-IS for IP Internets Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Held for Document Update] RFC7810 (5293)
The following errata report has been held for document update for RFC7810, "IS-IS Traffic Engineering (TE) Metric Extensions". -- You may review the report below and at: http://www.rfc-editor.org/errata/eid5293 -- Status: Held for Document Update Type: Editorial Reported by: Jeffrey Haas Date Reported: 2018-03-22 Held by: Alvaro Retana (IESG) Section: 4.5-4.7 Original Text - 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type| Length| RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Residual Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 37 Length: 4 RESERVED: This field is reserved for future use Corrected Text -- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type| Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Residual Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 37 Length: 4 Notes - In sections 4.5, 4.6 and 4.7, a RESERVED field is in the diagram and the text. However, the length field of each of these TLVs is 4. The RESERVED field is thus not present and should be removed in future editions of this document. === The discussion in the WG is here: https://mailarchive.ietf.org/arch/msg/lsr/x5DlcGmwMPf9hvgL6mofNqGpbQA/ -- RFC7810 (draft-ietf-isis-te-metric-extensions-11) -- Title : IS-IS Traffic Engineering (TE) Metric Extensions Publication Date: May 2016 Author(s) : S. Previdi, Ed., S. Giacalone, D. Ward, J. Drake, Q. Wu Category: PROPOSED STANDARD Source : IS-IS for IP Internets Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Editorial Errata Reported] RFC7810 (5293)
The following errata report has been submitted for RFC7810, "IS-IS Traffic Engineering (TE) Metric Extensions". -- You may review the report below and at: http://www.rfc-editor.org/errata/eid5293 -- Type: Editorial Reported by: Jeffrey Haas Section: 4.5-4.7 Original Text - 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type| Length| RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Residual Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 37 Length: 4 RESERVED: This field is reserved for future use Corrected Text -- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type| Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Residual Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: 37 Length: 4 Notes - In sections 4.5, 4.6 and 4.7, a RESERVED field is in the diagram and the text. However, the length field of each of these TLVs is 4. The RESERVED field is thus not present and should be removed in future editions of this document. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC7810 (draft-ietf-isis-te-metric-extensions-11) -- Title : IS-IS Traffic Engineering (TE) Metric Extensions Publication Date: May 2016 Author(s) : S. Previdi, Ed., S. Giacalone, D. Ward, J. Drake, Q. Wu Category: PROPOSED STANDARD Source : IS-IS for IP Internets Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Held for Document Update] RFC5250 (5287)
The following errata report has been held for document update for RFC5250, "The OSPF Opaque LSA Option". -- You may review the report below and at: http://www.rfc-editor.org/errata/eid5287 -- Status: Held for Document Update Type: Editorial Reported by: Angelos Vassiliou Date Reported: 2018-03-14 Held by: Alvaro Retana (IESG) Section: 7 Original Text - inter-area procedures described in Section 6 of this document. Corrected Text -- inter-area procedures described in Section 5 of this document. Notes - Inter-Area Considerations are discussed in Section 5, not Section 6. -- RFC5250 (draft-ietf-ospf-rfc2370bis-05) -- Title : The OSPF Opaque LSA Option Publication Date: July 2008 Author(s) : L. Berger, I. Bryskin, A. Zinin, R. Coltun Category: PROPOSED STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Errata Rejected] RFC5309 (5007)
The following errata report has been rejected for RFC5309, "Point-to-Point Operation over LAN in Link State Routing Protocols". -- You may review the report below and at: http://www.rfc-editor.org/errata/eid5007 -- Status: Rejected Type: Technical Reported by: Alexander Vainshtein Date Reported: 2017-04-30 Rejected by: Alvaro Retana (IESG) Section: 4.3 Original Text - For the ARP implementation (which checks that the subnet of the source address of the ARP request matches the local interface address), this check needs to be relaxed for the unnumbered p2p-over-lan circuits. Corrected Text -- For the ARP implementation (which checks that the subnet of the source address of the ARP request matches the local interface address), this check needs to be relaxed for the p2p-over-lan circuits (both numbered and unnumbered). Notes - Consider the following situation: 1. Two routers, R1 and R2, are connected by a physical P2P Ethernet link 2. OSPFv2 is enabled on the interfaces representing the endpoints of this link. 3. From the OSPF POV these interfaces: o Are configured as P2P o Belong to the same area o Are assigned with IP addresses and subnet masks yielding different subnets 4.ARP check mentioned in the problematic text is not relaxed. Under this conditions: -Both R1 and R2 will accept Hello messages sent by the other router (becase it ignores subnet in Hello messages received via P2P interfaces) - Adjacency between R1 and R2 will progress to FULL state (because all OSPFv2 messages will be sent with AllSPFRouters multicast IPv4 address) - Unicast traffic sent by R1 to R2 (and vice versa) will be blackholed because ARP will not resolve addresses assigned to the corresponding interfaces. --VERIFIER NOTES-- RFC 5309 introduced the possibility of supporting an unnumbered configuration on a LAN. Statements in this RFC regarding ARP concerns are therefore deliberately limited to this new configuration. For IS-IS, RFC 3787 Section 10 discusses concerns regarding mismatched subnets on numbered links. For OSPF it is well known that there are some existing implementations which have supported mismatched subnets for many years. Any concerns with ARP behavior in support of mismatched subnets on numbered LANs is out of scope of RFC 5309. [https://mailarchive.ietf.org/arch/msg/isis-wg/aCFWc8KuE8xEy0-qIrN63odct1o/?qid=623f2d68947e2ec849fb2e2a7f2e6242] -- RFC5309 (draft-ietf-isis-igp-p2p-over-lan-06) -- Title : Point-to-Point Operation over LAN in Link State Routing Protocols Publication Date: October 2008 Author(s) : N. Shen, Ed., A. Zinin, Ed. Category: INFORMATIONAL Source : IS-IS for IP Internets Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Editorial Errata Reported] RFC5250 (5287)
The following errata report has been submitted for RFC5250, "The OSPF Opaque LSA Option". -- You may review the report below and at: http://www.rfc-editor.org/errata/eid5287 -- Type: Editorial Reported by: Angelos Vassiliou Section: 7 Original Text - inter-area procedures described in Section 6 of this document. Corrected Text -- inter-area procedures described in Section 5 of this document. Notes - Inter-Area Considerations are discussed in Section 5, not Section 6. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC5250 (draft-ietf-ospf-rfc2370bis-05) -- Title : The OSPF Opaque LSA Option Publication Date: July 2008 Author(s) : L. Berger, I. Bryskin, A. Zinin, R. Coltun Category: PROPOSED STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
