[Lsr] Protocol Action: 'Revision to Registration Procedures for IS-IS Neighbor Link-Attribute Bit Values' to Proposed Standard (draft-ietf-lsr-labv-registration-03.txt)
The IESG has approved the following document: - 'Revision to Registration Procedures for IS-IS Neighbor Link-Attribute Bit Values' (draft-ietf-lsr-labv-registration-03.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Gunter Van de Velde, Jim Guichard and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-labv-registration/ Technical Summary RFC 5029, "Definition of an IS-IS Link Attribute Sub-TLV", defines a registry for "IS-IS Neighbor Link-Attribute Bit Values". This document changes the registration procedure for that registry from "Standards Action" to "Expert Review". Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was absolute consensus this draft is useful, needed and complete. The WG would like to fast track this document so that future pending temporary allocations can be avoided Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? Document quality is good. This draft intends to change an IANA registry procedure from "Standards Action" to "Expert Review" to allow experimental track documents to obtain code points and avoid perpetual renewing of requested code points for aforementioned type drafts/rfcs Personnel The Document Shepherd for this document is Yingzhen Qu. The Responsible Area Director is Gunter Van de Velde. IANA Note (Insert IANA Note here or remove section) > IANA Question --> Should [ RFC-to-be ] be added to the references for the > IS-IS Neighbor Link-Attribute Bit Values registry as a result of this change? Answer: Yes, that would make sense. This would allow people following the references to understand why the registry is no longer exactly the way that it was originally created. ___ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
[Lsr] Last Call: (Revision to Registration Procedures for IS-IS Neighbor Link-Attribute Bit Values) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Revision to Registration Procedures for IS-IS Neighbor Link-Attribute Bit Values' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-06-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract RFC 5029, "Definition of an IS-IS Link Attribute Sub-TLV", defines a registry for "IS-IS Neighbor Link-Attribute Bit Values". This document changes the registration procedure for that registry from "Standards Action" to "Expert Review". The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-labv-registration/ No IPR declarations have been submitted directly on this I-D. ___ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
[Lsr] Document Action: 'IS-IS Fast Flooding' to Experimental RFC (draft-ietf-lsr-isis-fast-flooding-11.txt)
The IESG has approved the following document: - 'IS-IS Fast Flooding' (draft-ietf-lsr-isis-fast-flooding-11.txt) as Experimental RFC This document is the product of the Link State Routing Working Group. The IESG contact persons are Gunter Van de Velde, Jim Guichard and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/ Technical Summary Current Link State Protocol Data Unit (PDU) flooding rates are much slower than what modern networks can support. The use of IS-IS at larger scale requires faster flooding rates to achieve desired convergence goals. This document discusses the need for faster flooding, the issues around faster flooding, and some example approaches to achieve faster flooding. It also defines protocol extensions relevant to faster flooding. Working Group Summary Per the shepherd writeup, "There is a strong consensus for this document. Interest peaked during its intial discussion and evolution and many WG memebers contributed to the discussion." Document Quality The shepherd writeup mentions about implementations, "There are existing implementation of both advertising and interpreting the new TLV and sub-TLVs. While are variations of the implemented fast-flooding algorithms, all the implementations adhere to the principles in section 6." There was an extensive TSVART review by Mirja Kuehlewind, which the authors worked through with her. Personnel The Document Shepherd for this document is Acee Lindem. The Responsible Area Director is John Scudder. ___ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
[Lsr] Document Action: 'Dynamic Flooding on Dense Graphs' to Experimental RFC (draft-ietf-lsr-dynamic-flooding-18.txt)
The IESG has approved the following document: - 'Dynamic Flooding on Dense Graphs' (draft-ietf-lsr-dynamic-flooding-18.txt) as Experimental RFC This document is the product of the Link State Routing Working Group. The IESG contact persons are Gunter Van de Velde, Jim Guichard and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/ Technical Summary Routing with link state protocols in dense network topologies can result in sub-optimal convergence times due to the overhead associated with flooding. This can be addressed by decreasing the flooding topology so that it is less dense. This document discusses the problem in some depth and an architectural solution. Specific protocol changes for IS-IS, OSPFv2, and OSPFv3 are described in this document. Working Group Summary Per the shepherd writeup, "Initially, there was a controversy with respect to distributed vs centralized computation of the flooding topology. The draft evolved to support either model." Document Quality Per the shepherd writeup, "There is one existing implementation. It is not reported formally due to a change in affiliation of the primary author." Personnel The Document Shepherd for this document is Acee Lindem. The Responsible Area Director is John Scudder. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (IS-IS Fast Flooding) to Experimental RFC
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Fast Flooding' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-02-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Current Link State Protocol Data Unit (PDU) flooding rates are much slower than what modern networks can support. The use of IS-IS at larger scale requires faster flooding rates to achieve desired convergence goals. This document discusses the need for faster flooding, the issues around faster flooding, and some example approaches to achieve faster flooding. It also defines protocol extensions relevant to faster flooding. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/5797/ https://datatracker.ietf.org/ipr/5323/ https://datatracker.ietf.org/ipr/3823/ https://datatracker.ietf.org/ipr/5205/ https://datatracker.ietf.org/ipr/3670/ https://datatracker.ietf.org/ipr/5336/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (Dynamic Flooding on Dense Graphs) to Experimental RFC
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Dynamic Flooding on Dense Graphs' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-02-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Routing with link state protocols in dense network topologies can result in sub-optimal convergence times due to the overhead associated with flooding. This can be addressed by decreasing the flooding topology so that it is less dense. This document discusses the problem in some depth and an architectural solution. Specific protocol changes for IS-IS, OSPFv2, and OSPFv3 are described in this document. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3361/ https://datatracker.ietf.org/ipr/3684/ https://datatracker.ietf.org/ipr/3686/ https://datatracker.ietf.org/ipr/4044/ https://datatracker.ietf.org/ipr/4017/ https://datatracker.ietf.org/ipr/3164/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'YANG Model for OSPFv3 Extended LSAs' to Proposed Standard (draft-ietf-lsr-ospfv3-extended-lsa-yang-29.txt)
The IESG has approved the following document: - 'YANG Model for OSPFv3 Extended LSAs' (draft-ietf-lsr-ospfv3-extended-lsa-yang-29.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ Technical Summary This document defines a YANG data model augmenting the IETF OSPF YANG model to provide support for OSPFv3 Link State Advertisement (LSA) Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340. Working Group Summary The shepherd writeup notes "Strong concurrence of a few individuals." There were a few reviews during IETF last call that were addressed. Document Quality The shepherd writeup notes "a YANG doctors review was performed" and "Checked with `yanglint` and `pyang --ietf`". Personnel The Document Shepherd for this document is Christian Hopps. The Responsible Area Director is John Scudder. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Document Action: 'Area Proxy for IS-IS' to Experimental RFC (draft-ietf-lsr-isis-area-proxy-12.txt)
The IESG has approved the following document: - 'Area Proxy for IS-IS' (draft-ietf-lsr-isis-area-proxy-12.txt) as Experimental RFC This document is the product of the Link State Routing Working Group. The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/ Technical Summary Link state routing protocols have hierarchical abstraction already built into them. However, when lower levels are used for transit, they must expose their internal topologies to each other, leading to scale issues. To avoid this, this document discusses extensions to the IS-IS routing protocol that allow level 1 areas to provide transit, yet only inject an abstraction of the level 1 topology into level 2. Each level 1 area is represented as a single level 2 node, thereby enabling greater scale. Working Group Summary Shepherd writeup indicates broad consensus and no controversy. The WG agreed on experimental track for this document. Document Quality Shepherd writeup mentions one known shipping implementation. Personnel The Document Shepherd for this document is Christian Hopps. The Responsible Area Director is John Scudder. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'YANG Model for OSPFv3 Extended LSAs' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-01-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG data model augmenting the IETF OSPF YANG model to provide support for OSPFv3 Link State Advertisement (LSA) Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ No IPR declarations have been submitted directly on this I-D. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (Area Proxy for IS-IS) to Experimental RFC
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Area Proxy for IS-IS' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-12-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Link state routing protocols have hierarchical abstraction already built into them. However, when lower levels are used for transit, they must expose their internal topologies to each other, leading to scale issues. To avoid this, this document discusses extensions to the IS-IS routing protocol that allow level 1 areas to provide transit, yet only inject an abstraction of the level 1 topology into level 2. Each level 1 area is represented as a single level 2 node, thereby enabling greater scale. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/4016/ https://datatracker.ietf.org/ipr/3357/ https://datatracker.ietf.org/ipr/3221/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'IGP Flexible Algorithms (Flex-Algorithm) In IP Networks' to Proposed Standard (draft-ietf-lsr-ip-flexalgo-16.txt)
The IESG has approved the following document: - 'IGP Flexible Algorithms (Flex-Algorithm) In IP Networks' (draft-ietf-lsr-ip-flexalgo-16.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/ Technical Summary An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute constraint-based paths. The base IGP Flex-Algorithm specification describes how it is used with Segment Routing (SR) data planes - SR MPLS and SRv6. This document extends IGP Flex-Algorithm, so that it can be used with regular IPv4 and IPv6 forwarding. Working Group Summary From the shepherd writeup: We had a great discussion of the use cases and terminology and, as a result, there will be changes in the version submitted for publication. One individual WG member strongly suggested a solution that wouldn't interoperate with routers not supporting Flex Algo. However, it is not uncommon for this WG member to be in the minority. Document Quality From the shepherd writeup: Cisco IOS-XR has an implementation that is shipping for IS-IS. Juniper has an implementation that has not yet shipped. Personnel The Document Shepherd for this document is Acee Lindem. The Responsible Area Director is John Scudder. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'OSPFv3 Extensions for SRv6' to Proposed Standard (draft-ietf-lsr-ospfv3-srv6-extensions-15.txt)
The IESG has approved the following document: - 'OSPFv3 Extensions for SRv6' (draft-ietf-lsr-ospfv3-srv6-extensions-15.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/ Technical Summary The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called segments. It can be implemented over an MPLS or IPv6 data plane. This document describes the OSPFv3 extensions required to support Segment Routing over the IPv6 data plane (SRv6). Working Group Summary There was no real controversy although there was discussion as to whether it was a good idea to have separate Link State Advertisements (LSAs) for the SRv6 Locators as opposed to using the existing LSAs. Unlike IS-IS, one of the advantages of OSPFv3 is that disjoint information can be advertised in separate LSAs. Review by OSPFv3 implementors revealed that the OSPFv3 PrefixOptions needed to be advertised in the SRv6 Locator TLV. This specification adds the AC-Bit (AnyCast Bit) which is applicable to all usages of the OSPFv3 PrefixOptions. Document Quality The shepherd's report notes nothing exceptional, and doesn't identify any implementations other than "a Huawei implemenation underway but it has not been released yet and there is no report." Personnel The Document Shepherd for this document is Acee Lindem. The Responsible Area Director is John Scudder. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'OSPF Application-Specific Link Attributes' to Proposed Standard (draft-ietf-lsr-rfc8920bis-06.txt)
The IESG has approved the following document: - 'OSPF Application-Specific Link Attributes' (draft-ietf-lsr-rfc8920bis-06.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8920bis/ Technical Summary This bis document is a narrowly-scoped update to RFC 8920. The updates are outlined in Section 15, "Changes to RFC 8920". Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements in OSPFv2 and OSPFv3 that address both of these shortcomings. This document obsoletes RFC 8920. Working Group Summary The document shepherd notes broad agreement and no controversy (though note the one dissenting opinion that applied to rfc8919bis, and that was judged to be out of scope and in the rough, quite likely applies here as well). Document Quality The shepherd notes, "Implementations of the base document exist." The scope of the bis doesn't require specialized review. Personnel The Document Shepherd for this document is Christian Hopps. The Responsible Area Director is John Scudder. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'IS-IS Application-Specific Link Attributes' to Proposed Standard (draft-ietf-lsr-rfc8919bis-04.txt)
The IESG has approved the following document: - 'IS-IS Application-Specific Link Attributes' (draft-ietf-lsr-rfc8919bis-04.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8919bis/ Technical Summary This bis document is a narrowly-scoped update to RFC 8919. The updates are outlined in Section 9, "Changes to RFC 8919". Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements that address both of these shortcomings. This document obsoletes RFC 8919. Working Group Summary The document shepherd notes, "one person expressed dislike for the base document; however, that was deemed out-of-scope as this is a simple clarifying document update." In other respects the shepherd notes broad WG agreement to publish. Document Quality The shepherd notes, "Implementations of the base document exist." The scope of the bis doesn't require specialized review. Personnel The Document Shepherd for this document is Christian Hopps. The Responsible Area Director is John Scudder. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'Update to OSPF Terminology' to Proposed Standard (draft-ietf-lsr-ospf-terminology-09.txt)
The IESG has approved the following document: - 'Update to OSPF Terminology' (draft-ietf-lsr-ospf-terminology-09.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-terminology/ Technical Summary This document updates some OSPF terminology to be in line with inclusive language used in the industry. The IETF has designated National Institute of Standards and Technology (NIST) "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards" for its inclusive language guidelines. This document updates RFC2328, RFC5340, RFC4222, RFC4811, RFC5243, RFC5614, and RFC5838. Working Group Summary The document shepherd's report indicates there was no controversy, and that there was broad agreement to publish. Document Quality The document doesn't specify a protocol, it updates terminology. The updates have been thoroughly reviewed. Personnel The Document Shepherd for this document is Christian Hopps. The Responsible Area Director is John Scudder. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (IGP Flexible Algorithms (Flex-Algorithm) In IP Networks) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IGP Flexible Algorithms (Flex-Algorithm) In IP Networks' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-05-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute constraint-based paths. The base IGP Flex-Algorithm specification describes how it is used with Segment Routing (SR) data planes - SR MPLS and SRv6. This document extends IGP Flex-Algorithm, so that it can be used with regular IPv4 and IPv6 forwarding. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/4317/ https://datatracker.ietf.org/ipr/4519/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (OSPFv3 Extensions for SRv6) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'OSPFv3 Extensions for SRv6' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-05-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called segments. It can be implemented over an MPLS or IPv6 data plane. This document describes the OSPFv3 extensions required to support Segment Routing over the IPv6 data plane (SRv6). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/5785/ https://datatracker.ietf.org/ipr/3980/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (OSPF Application-Specific Link Attributes) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'OSPF Application-Specific Link Attributes' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-05-04. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Note the extreme similarity between this document and its companion document, draft-ietf-lsr-rfc8919bis-00, which also entered last call recently. Abstract Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements in OSPFv2 and OSPFv3 that address both of these shortcomings. This document obsoletes RFC 8920. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8920bis/ No IPR declarations have been submitted directly on this I-D. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (IS-IS Application-Specific Link Attributes) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Application-Specific Link Attributes' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-05-03. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements that address both of these shortcomings. This document obsoletes RFC 8919. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8919bis/ No IPR declarations have been submitted directly on this I-D. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (Update to OSPF Terminology) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Update to OSPF Terminology' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-05-03. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates some OSPF terminology to be in line with inclusive language used in the industry. The IETF has designated National Institute of Standards and Technology (NIST) "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards" for its inclusive language guidelines. This document updates RFC2328, RFC5340, RFC4222, RFC4811, RFC5243, RFC5614, and RFC5838. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-terminology/ No IPR declarations have been submitted directly on this I-D. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Document Action: 'IS-IS Flood Reflection' to Experimental RFC (draft-ietf-lsr-isis-flood-reflection-12.txt)
The IESG has approved the following document: - 'IS-IS Flood Reflection' (draft-ietf-lsr-isis-flood-reflection-12.txt) as Experimental RFC This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Andrew Alston and John Scudder. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-flood-reflection/ Technical Summary: This document provides extensions to IS-IS to support flooding reflection of IS-IS updates in a level-1 area used for level-2 transit. This reduces the requirement for a full mesh of adjacencies between Area Border Routers (ABRs) and allows the flooding reflection to be done by the server which doesn't necessarily participate in the data plane. The document also describes bbut tunneled and non-tunneled transit in the level-1 area. Working Group Summary: There is stong support among those reviewing the document. However, there was at least one WG participant who thought the WG would select one of the alternatives among those proposed rather than advancing experimental solutions with sufficent momentum. Document Quality: The document is of high quality although at least WG member believed the solution was too complex. Personnel: Document Shepherd: Acee Lindem Responsible AD: John Scudder ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'IGP extension for PCEP security capability support in PCE discovery' to Proposed Standard (draft-ietf-lsr-pce-discovery-security-support-13.txt)
The IESG has approved the following document: - 'IGP extension for PCEP security capability support in PCE discovery' (draft-ietf-lsr-pce-discovery-security-support-13.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Andrew Alston and John Scudder. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/ Technical Summary This document provides extensions to OSPF and IS-IS to advertisement the PCE Security capabilities of the advertising router. These capabilities could than be used for PCE and PC Client authentication. Working Group Summary While this document has been around for some time, there wasn't much discussion until WG last call. During the WG last call, we received comments from more than a half dozen people and these were incorporated into the document. We also got RTG and SEC directorate reviews. The WG last call included both the LSR and PCE WG lists and there were reviewers from both. Document Quality The document is of high quality with all the required reviews. While there aren't any implementations yet, it is a very straight forward extension. Personnel Document Shepherd: Acee Lindem Responsible AD: John Scudder ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'OSPF Reverse Metric' to Proposed Standard (draft-ietf-lsr-ospf-reverse-metric-13.txt)
The IESG has approved the following document: - 'OSPF Reverse Metric' (draft-ietf-lsr-ospf-reverse-metric-13.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Andrew Alston and John Scudder. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/ Technical Summary This document provides extensions to OSPF to support dynamic modification of link metrics by ingress router on the link. In other words, an OSPF router can request an adjacent OSPF router to advertise a higher link metric. Working Group Summary Given that the draft is implementing function already supported for IS-IS with RFC 8500, there wasn't a lot of excitement over the draft. During the WG last call, a number of WG members the draft with the only issue being the predominant use cases. The draft is generally supported. Document Quality The document describes a relatively simple OSPF extension and is analogous to similar function in IS-IS (RFC 8500). It is of high quality and ready for publication. Personnel Document Shepherd: Acee Lindem Responsible AD: John Scudder ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'Advertising Layer 2 Bundle Member Link Attributes in OSPF' to Proposed Standard (draft-ietf-lsr-ospf-l2bundles-10.txt)
The IESG has approved the following document: - 'Advertising Layer 2 Bundle Member Link Attributes in OSPF' (draft-ietf-lsr-ospf-l2bundles-10.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Andrew Alston and John Scudder. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-l2bundles/ Technical Summary There are deployments where the Layer 3 (L3) interface on which OSPF operates is a Layer 2 (L2) interface bundle. Existing OSPF advertisements only support advertising link attributes of the Layer 3 interface. If entities external to OSPF wish to control traffic flows on the individual physical links which comprise the Layer 2 interface bundle, link attribute information for the bundle members is required. This document defines the protocol extensions for OSPF to advertise the link attributes of L2 bundle members. Working Group Summary This document is definitely needed analogous to RFC 8668. Given that it is a protocol maintenance document, it has not generated a lot of excitement in the LSR WG. During WG discussion there was no controversy over any points. Document Quality There are no reported implementations. Stewart Bryant provided a Routing Directorate review and agreed the document is ready for publication. Personnel Document Shepherd: Acee Lindem Responsible Area Director: John Scudder ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'IGP Flexible Algorithm' to Proposed Standard (draft-ietf-lsr-flex-algo-25.txt)
The IESG has approved the following document: - 'IGP Flexible Algorithm' (draft-ietf-lsr-flex-algo-25.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Andrew Alston and John Scudder. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/ Technical Summary: This document provides extensions to OSPF and IS-IS to use different algorithms to compute the paths to different prefixes. Since not all nodes in the computation domain (i.e., an OSPF or IS-IS area) may support every algorithm, SR or SRv6 is used to between nodes. Working Group Summary: The was good collaboration on the document. The only controversy came at the tail end of the process when there was some discussion as to whether RFC 8919 /RFC 8920 Application Specific Link Attributes (ASLAs) should be used for alternate metrics or whether the advetisements used for RSVP TE could also be used. The consensus was to allow RFC 8919/RFC 8920 attributes to be required. Discussion and implementation uncovered that some additional OSPF encodings were needed for ASBR routes. This resulted in updates and second WG Last Call. During the second WG Last Call, the discussion of the application specific attributes resulted in Errata to both RFC 8919 and 8920: https://www.rfc-editor.org/errata/eid6631 https://www.rfc-editor.org/errata/eid6630 Document Quality: The document is of high quality with vendors and operators reviewing. There are existing implementations of the document and three other WG documents that augment the base document: https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/ https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/ https://datatracker.ietf.org/doc/draft-ietf-lsr-algorithm-related-adjacency-sid/ Personnel: Document Shepherd: Acee Lindem Responsible AD: John Scudder ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'OSPF BFD Strict-Mode' to Proposed Standard (draft-ietf-lsr-ospf-bfd-strict-mode-10.txt)
The IESG has approved the following document: - 'OSPF BFD Strict-Mode' (draft-ietf-lsr-ospf-bfd-strict-mode-10.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Andrew Alston and John Scudder. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/ Technical Summary This document provides extensions to OSPF to require a BFD session (i.e., strict-mode) prior to OSPF adjacency formation. Extensions are provided both OSPF Link-Local-Signaling to advertise the desire to require a BFD session and to the OSPF neighbor FSM should BFD strict-mode be successfully negotiated. Working Group Summary There is stong support among those reviewing the document. The WG last call of the document prompted discussions of additional specification. There was debate regarding making the delay timer described in section 5 a normative requirement. The consensus was to not make this a normative part of the specification. The shepherd felt this is the right decision – especially given that this is new functionality being requested at Working Group Last Call and implementations accomplish the dampening in varying ways. Document Quality The document is of high quality and has been reviewed by several LSR WG members. This same function is already standardized for IS-IS [RFC6213] Personnel Document Shepherd: Acee Lindem Responsible AD: John Scudder ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering' to Proposed Standard (draft-ietf-lsr-isis-rfc5316bis-07.txt)
The IESG has approved the following document: - 'IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering' (draft-ietf-lsr-isis-rfc5316bis-07.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Andrew Alston and John Scudder. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/ Technical Summary This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASs). It defines IS-IS extensions for the flooding of TE information about inter-AS links, which can be used to perform inter-AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. This document builds on RFC 5316 by adding support for IPv6-only operation. This document obsoletes RFC 5316. Working Group Summary "Generally smooth" Document Quality "Unsure if existing implementations yet; however, I believe this will be implemented by most vendors." Personnel Shepherd: Christian Hopps AD: John Scudder ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (IS-IS Flood Reflection) to Experimental RFC
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Flood Reflection' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2022-10-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a backward-compatible, optional IS-IS extension that allows the creation of IS-IS flood reflection topologies. Flood reflection permits topologies in which L1 areas provide transit forwarding for L2 using all available L1 nodes internally. It accomplishes this by creating L2 flood reflection adjacencies within each L1 area. Those adjacencies are used to flood L2 LSPDUs and are used in the L2 SPF computation. However, they are not ordinarily utilized for forwarding within the flood reflection cluster. This arrangement gives the L2 topology significantly better scaling properties than traditionally used flat designs. As an additional benefit, only those routers directly participating in flood reflection are required to support the feature. This allows for incremental deployment of scalable L1 transit areas in an existing, previously flat network design, without the necessity of upgrading all routers in the network. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-flood-reflection/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/4186/ https://datatracker.ietf.org/ipr/5807/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (Advertising Layer 2 Bundle Member Link Attributes in OSPF) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Advertising Layer 2 Bundle Member Link Attributes in OSPF' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2022-09-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract There are deployments where the Layer 3 (L3) interface on which OSPF operates is a Layer 2 (L2) interface bundle. Existing OSPF advertisements only support advertising link attributes of the Layer 3 interface. If entities external to OSPF wish to control traffic flows on the individual physical links which comprise the Layer 2 interface bundle, link attribute information for the bundle members is required. This document defines the protocol extensions for OSPF to advertise the link attributes of L2 bundle members. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-l2bundles/ No IPR declarations have been submitted directly on this I-D. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (IGP Flexible Algorithm) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IGP Flexible Algorithm' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2022-09-26. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract IGP protocols traditionally compute best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE based or Segment Routing based Traffic Engineering to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3248/ https://datatracker.ietf.org/ipr/3910/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (OSPF Reverse Metric) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'OSPF Reverse Metric' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2022-09-20. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the extensions to OSPF that enable a router to use link-local signaling to signal the metric that receiving neighbor(s) should use for a link to the signaling router. The signaling of this reverse metric, to be used on the link to the signaling router, allows a router to influence the amount of traffic flowing towards itself and in certain use cases enables routers to maintain symmetric metrics on both sides of a link between them. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/ No IPR declarations have been submitted directly on this I-D. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (OSPF BFD Strict-Mode) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'OSPF BFD Strict-Mode' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2022-09-20. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the extensions to OSPF that enable an OSPF router to signal the requirement for a Bidirectional Forwarding Detection (BFD) session prior to adjacency formation. Link-Local Signaling (LLS) is used to advertise the requirement for strict-mode BFD session establishment for an OSPF adjacency. If both OSPF neighbors advertise BFD strict-mode, adjacency formation will be blocked until a BFD session has been successfully established. This document updates RFC2328 by augmenting the OSPF neighbor state machine with a check for BFD session up before progression from Init to Two-Way state when operating in OSPF BFD strict-mode. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/ No IPR declarations have been submitted directly on this I-D. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (IGP extension for PCEP security capability support in PCE discovery) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IGP extension for PCEP security capability support in PCE discovery' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2022-09-20. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract When a Path Computation Element (PCE) is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating in the IGP, its presence and path computation capabilities can be advertised using IGP flooding. The IGP extensions for PCE discovery (RFC 5088 and RFC 5089) define a method to advertise path computation capabilities using IGP flooding for OSPF and IS-IS respectively. However these specifications lack a method to advertise PCE Communication Protocol (PCEP) security (e.g., Transport Layer Security (TLS), TCP Authentication Option (TCP-AO)) support capability. This document defines capability flag bits for the PCE-CAP-FLAGS sub- TLV that can be announced as an attribute in the IGP advertisement to distribute PCEP security support information. In addition, this document updates RFC 5088 and RFC 5089 to allow advertisement of a Key ID or Key Chain Name Sub-TLV to support TCP-AO security capability. Further, this document updates RFC 8231, and RFC 8306. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/5027/ https://datatracker.ietf.org/ipr/3351/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2022-09-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASs). It defines IS-IS extensions for the flooding of TE information about inter-AS links, which can be used to perform inter-AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. This document builds on RFC 5316 by adding support for IPv6-only operation. This document obsoletes RFC 5316. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/4665/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'YANG Module for IS-IS Reverse Metric' to Proposed Standard (draft-ietf-lsr-yang-isis-reverse-metric-06.txt)
The IESG has approved the following document: - 'YANG Module for IS-IS Reverse Metric' (draft-ietf-lsr-yang-isis-reverse-metric-06.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, John Scudder and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-reverse-metric/ Technical Summary: The document defines YANG model that augments the base ietf-isis.yang model. It provides augmentations supporting configuration and operational data for the IS-IS reverse metric functionality as described in RFC 8500. Working Group Summary: The document has been reviewed by the YANG experts in the LSR working group and has been reviewed by both the YANG doctors and routing area directorate. Document Quality: The document is a fairly simple extension to the existing IS-IS YANG model. IS-IS experts have been quieried to validate that it meets the requirments for IS-IS reverse metric configuration and operational state. Personnel: Acee Lindem is the Document Shepherd. John Scudder is the Responsible Area Director. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (YANG Module for IS-IS Reverse Metric) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'YANG Module for IS-IS Reverse Metric' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-11-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG module for managing the reverse metric extension to the Intermediate System to Intermediate System intra- domain routeing information exchange protocol (IS-IS). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-reverse-metric/ No IPR declarations have been submitted directly on this I-D. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'IS-IS Extensions to Support Segment Routing over IPv6 Dataplane' to Proposed Standard (draft-ietf-lsr-isis-srv6-extensions-18.txt)
The IESG has approved the following document: - 'IS-IS Extensions to Support Segment Routing over IPv6 Dataplane' (draft-ietf-lsr-isis-srv6-extensions-18.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, John Scudder and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ Technical Summary This document describes the IS-IS extensions required to support Segment Routing over an IPv6 data plane. Working Group Summary There were some vigorous discussions with regards to the extensions (and the underlying technology being supported by the extensions), but nothing particularly rough in the resulting consensus on the extensions themselves. Document Quality There are multiple implementations of this work deployed. Personnel Shepherd: Christian Hopps AD: Alvaro Retana ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (IS-IS Extension to Support Segment Routing over IPv6 Dataplane) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Extension to Support Segment Routing over IPv6 Dataplane' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-05-07. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Segment Routing (SR) allows for a flexible definition of end-to- end paths by encoding paths as sequences of topological sub-paths, called "segments". Segment routing architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. This document describes the IS-IS extensions required to support Segment Routing over an IPv6 data plane. This documents updates RFC 7370 by modifying an existing registry. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3796/ https://datatracker.ietf.org/ipr/4486/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'OSPF Prefix Originator Extensions' to Proposed Standard (draft-ietf-lsr-ospf-prefix-originator-12.txt)
The IESG has approved the following document: - 'OSPF Prefix Originator Extensions' (draft-ietf-lsr-ospf-prefix-originator-12.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, John Scudder and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/ Technical Summary This document defines OSPF extensions to include information associated with the node originating a prefix along with the prefix advertisement. Working Group Summary There was a drawn-out discussion about a non-normative appendix that talked about a controversial use case. The WG (as well as some of the authors) did not support its inclusion; it was removed. Document Quality This draft is a simple extension that mirrors similar functionality in IS-IS. It's filling a gap in LSR. Personnel Shepherd: Christian Hopps AD: Alvaro Retana ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (OSPF Prefix Originator Extensions) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'OSPF Prefix Originator Extensions' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-03-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines OSPF extensions to include information associated with the node originating a prefix along with the prefix advertisement. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3448/ https://datatracker.ietf.org/ipr/3418/ https://datatracker.ietf.org/ipr/3419/ https://datatracker.ietf.org/ipr/3420/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'Invalid TLV Handling in IS-IS' to Proposed Standard (draft-ietf-lsr-isis-invalid-tlv-03.txt)
The IESG has approved the following document: - 'Invalid TLV Handling in IS-IS' (draft-ietf-lsr-isis-invalid-tlv-03.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ Technical Summary Key to the extensibility of the Intermediate System to Intermediate System (IS-IS) protocol has been the handling of unsupported and/or invalid Type/Length/Value (TLV) tuples. Although there are explicit statements in existing specifications, deployment experience has shown that there are inconsistencies in the behavior when a TLV which is disallowed in a particular Protocol Data Unit (PDU) is received. This document discusses such cases and makes the correct behavior explicit in order to ensure that interoperability is maximized. Working Group Summary The document was well received and the process straight forward. Document Quality Most implementations already follow what this document specifies. The implementations that do not must be updated. Personnel Document Shepherd: Christian Hopps Responsible AD: Alvaro Retana ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'OSPF Application-Specific Link Attributes' to Proposed Standard (draft-ietf-ospf-te-link-attr-reuse-16.txt)
The IESG has approved the following document: - 'OSPF Application-Specific Link Attributes' (draft-ietf-ospf-te-link-attr-reuse-16.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/ Technical Summary This document specifies extensions to OSPF to specify encoding for application specific link attributes. This will support both different attributes for applications and limiting the usage of attributes to specific applications. Backward compatibility considerations are also discussed. Working Group Summary Initially, there was a lot of debate as to whether or not this was required as some argued it could be done by just using the the MPLS and GMPLS TE encodings for other applications. After much debate consensus was reached. Document Quality This document has been a WG document for a multiple years. It is stable, without changes to the technical solution and only clarifications. Personnel Yingzhen Qu is the Document Shepherd. Alvaro Retana is the Responsible Area Director. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'IS-IS Application-Specific Link Attributes' to Proposed Standard (draft-ietf-isis-te-app-19.txt)
The IESG has approved the following document: - 'IS-IS Application-Specific Link Attributes' (draft-ietf-isis-te-app-19.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/ Technical Summary This document specifies extensions to ISIS to specify encoding for application specific link attributes. This will support both different attributes for applications and limiting the usage of attributes to specific applications. Backward compatibility considerations are also discussed. Working Group Summary There was initial objection to this work and the requirement for application specific attributes. However, after considerable debate, consensus was reached on the the document. Document Quality This document has been a WG document for a multiple years. It is stable, without changes to the technical solution and only clarifications. Personnel Acee Lindem is the Document Shepherd. Alvaro Retana is the Responsible Area Director. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (Invalid TLV Handling in IS-IS) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Invalid TLV Handling in IS-IS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-07-08. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Key to the extensibility of the Intermediate System to Intermediate System (IS-IS) protocol has been the handling of unsupported and/or invalid Type/Length/Value (TLV) tuples. Although there are explicit statements in existing specifications, deployment experience has shown that there are inconsistencies in the behavior when a TLV which is disallowed in a particular Protocol Data Unit (PDU) is received. This document discusses such cases and makes the correct behavior explicit in order to insure that interoperability is maximized. This document updates RFC5305 and RFC6232. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ No IPR declarations have been submitted directly on this I-D. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF' to Proposed Standard (draft-ietf-ospf-mpls-elc-15.txt)
The IESG has approved the following document: - 'Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF' (draft-ietf-ospf-mpls-elc-15.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/ Technical Summary This document specifies extensions to OSPFv2/OSPFv3 Prefix advertisement to indicate whether or not a prefix is Entropy Label Capable (ELC), i.e., eligible for entropy label processing. Additionally, a new MSD type is used to advertise the Entropy Readable Label Depth (ERLD). The ELRD will be advertised using the existing Maximum SID Depth (MSD) encodings defined in RFC 8476. Finally, the mapping of these extensions to existing BGP-LS encodigs is specified. Working Group Summary The draft went through multiple iterations due to a change in requirements. Originally, the ELC was a node-level attribute. However, a Service Provider (SP) use case relating to external prefix advertisement required per-prefix advertisement. A second change was required when the BGP-LS encodings specification was incorporated into the draft. Since this incorporation obviated the BGP-LS draft, a sixth author was added. Document Quality This document has been a WG document over 4 years. While it has gone through several iterations, we are now confident that it is ready for publication. Personnel Acee Lindem is the Document Shepherd. Alvaro Retana is the Responsible Area Director. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS' to Proposed Standard (draft-ietf-isis-mpls-elc-13.txt)
The IESG has approved the following document: - 'Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS' (draft-ietf-isis-mpls-elc-13.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/ Technical Summary This document specifies extensions to IS-IS Prefix attribute advertisement to indicate whether or not a prefix is Entropy Label Capable (ELC), i.e., eligible for entropy label processing. Additionally, a new MSD type is defined to advertise the Entropy Readable Label Depth (ERLD). The ELRD will be advertised using the existing Maximum SID Depth (MSD) encodings defined in RFC 8476. Finally, the mapping of these extensions to existing BGP-LS encodigs is specified. Working Group Summary The draft went through multiple iterations due to a change in requirements. Originally, the ELC was a node-level attribute. However, a Service Provider (SP) use case relating to external prefix advertisement required per-prefix advertisement. A second change was required when the BGP-LS encodings specification was incorporated into the draft. Since this incorporation obviated the BGP-LS draft, a sixth author was added. Document Quality This document has been a WG document over 4 years. While it has gone through several iterations, we are now confident that it is ready for publication. Personnel Acee Lindem is the Document Shepherd. Alvaro Retana is the Responsible Area Director. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (OSPF Link Traffic Engineering Attribute Reuse) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'OSPF Link Traffic Engineering Attribute Reuse' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-05-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Existing traffic engineering related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Traffic Engineering, Loop Free Alternate) have been defined which also make use of the link attribute advertisements. In cases where multiple applications wish to make use of these link attributes the current advertisements do not support application specific values for a given attribute nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements in OSPFv2 and OSPFv3 which address both of these shortcomings. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/ No IPR declarations have been submitted directly on this I-D. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (IS-IS TE Attributes per application) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS TE Attributes per application' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-05-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Existing traffic engineering related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Traffic Engineering, Loop Free Alternate) have been defined which also make use of the link attribute advertisements. In cases where multiple applications wish to make use of these link attributes the current advertisements do not support application specific values for a given attribute nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements which address both of these shortcomings. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/ No IPR declarations have been submitted directly on this I-D. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-05-05. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Multiprotocol Label Switching (MPLS) has defined a mechanism to load- balance traffic flows using Entropy Labels (EL). An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that tunnel. In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load- balancing, referred to as Entropy Readable Label Depth (ERLD). This document defines a mechanism to signal these two capabilities using OSPFv2 and OSPFv3. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2313/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-05-05. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Multiprotocol Label Switching (MPLS) has defined a mechanism to load- balance traffic flows using Entropy Labels (EL). An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that tunnel. In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load- balancing, referred to as Entropy Readable Label Depth (ERLD). This document defines a mechanism to signal these two capabilities using IS-IS. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2311/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'Host Router Support for OSPFv2' to Proposed Standard (draft-ietf-ospf-ospfv2-hbit-12.txt)
The IESG has approved the following document: - 'Host Router Support for OSPFv2' (draft-ietf-ospf-ospfv2-hbit-12.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/ Technical Summary The Open Shortest Path First Version 2 (OSPFv2) does not have a mechanism for a node to repel transit traffic if it is on the shortest path. This document defines a bit (Host-bit) that enables a router to advertise that it is a non-transit router." It also describes the changes needed to support the H-bit in the domain. In addition, this document updates RFC 6987 to advertise type-2 External and NSSA LSAs with a high cost in order to repel traffic effectively. Working Group Summary Except for a long processing time, the draft has strong WG support. Document Quality This is a straight forward draft, and similar function exists in ISIS and OSPFv3. Personnel Yingzhen Qu is the Document Shepherd. Alvaro Retana is the Responsible Area Director. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (Host Router Support for OSPFv2) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Host Router Support for OSPFv2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2019-11-07. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Open Shortest Path First Version 2 (OSPFv2) does not have a mechanism for a node to repel transit traffic if it is on the shortest path. This document defines a bit (Host-bit) that enables a router to advertise that it is a non-transit router." It also describes the changes needed to support the H-bit in the domain. In addition, this document updates RFC 6987 to advertise type-2 External and NSSA LSAs with a high cost in order to repel traffic effectively. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/ballot/ No IPR declarations have been submitted directly on this I-D. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'YANG Data Model for IS-IS Protocol' to Proposed Standard (draft-ietf-isis-yang-isis-cfg-42.txt)
The IESG has approved the following document: - 'YANG Data Model for IS-IS Protocol' (draft-ietf-isis-yang-isis-cfg-42.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/ Technical Summary This document defines a YANG data model that can be used to configure and manage the IS-IS protocol on network elements. Working Group Summary The current document represents a proper management framework for the most commonly deployed ISIS features covered in various ISIS RFCs. Document Quality There are currently no known implementations of this YANG module. Expert review was done by the YANG Doctors. All comments have been addressed, and there are no open issues. Personnel Yingzhen Qu is the Document Shepherd. Alvaro Retana is the Responsible Area Director. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'Restart Signaling for IS-IS' to Proposed Standard (draft-ietf-lsr-isis-rfc5306bis-09.txt)
The IESG has approved the following document: - 'Restart Signaling for IS-IS' (draft-ietf-lsr-isis-rfc5306bis-09.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5306bis/ Technical Summary This document is a (mostly) editorial revision of rfc5306, plus new functionality for a router to signal its neighbors that it is preparing to initiate a restart while maintaining forwarding plane state. Working Group Summary There is no much working group discussion on the enhancement presented in the bis document. But, the draft has been presented in the LSR WG meeting(s). The draft adoption and progress has received good support from the WG. No major concerns have been raised. Document Quality rfc5306 is widely deployed. The new functionality has been implemented by at least one vendor. Personnel Uma Chunduri is the Document Shepherd. Alvaro Retana is the Responsible Area Director. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (YANG Data Model for IS-IS Protocol) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'YANG Data Model for IS-IS Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2019-09-23. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG data model that can be used to configure and manage IS-IS protocol on network elements. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/ballot/ No IPR declarations have been submitted directly on this I-D. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'OSPF Routing with Cross-Address Family Traffic Engineering Tunnels' to Proposed Standard (draft-ietf-ospf-xaf-te-07.txt)
The IESG has approved the following document: - 'OSPF Routing with Cross-Address Family Traffic Engineering Tunnels' (draft-ietf-ospf-xaf-te-07.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Deborah Brungard and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/ Technical Summary This document specifies extensions to OSPF Traffic Engineering to include allow tunnel endpoints for both IPv4 and IPv6 to be advertised in the OSPF traffic engineering LSAs for either OSPFv2 or OSPFv3. In cases where the topologies are congruent, this allows TE information to be only advertised in one of the two. Non-normative text also describes how this information is used across address families in the TE tunnel computation. Working Group Summary There has been some confusion on how this is used and the draft has gone through iterations to separate the normative advertisement from the TE tunnel computation itself. This has now been clarified and there are no objections to the draft. Document Quality This document has been a WG document for a multiple years. It is stable, without changes to the technical solution and only clarifications, as well as, separation of the advertisement from the TE tunnel computation. Personnel Acee Lindem is the Document Shepherd. Martin Vigoureux is the Responsible AD, on behalf of Alvaro Retana ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'YANG Data Model for OSPF Protocol' to Proposed Standard (draft-ietf-ospf-yang-28.txt)
The IESG has approved the following document: - 'YANG Data Model for OSPF Protocol' (draft-ietf-ospf-yang-28.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/ Technical Summary This document defines a YANG data model that can be used to configure and manage OSPF. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NDMA) as described in RFC 8342. Working Group Summary Straight forward process in the WG. Document Quality The document has been reviewed by a YANG doctor and his comments have been addressed in the latest revisions. Personnel Stephane Litkowski is the document shepherd. Alvaro Retana is the responsible AD. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (Restart Signaling for IS-IS) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Restart Signaling for IS-IS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2019-08-27. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. This document additionally describes a mechanism for a router to signal its neighbors that it is preparing to initiate a restart while maintaining forwarding plane state. This allows the neighbors to maintain their adjacencies until the router has restarted, but also allows the neighbors to bring the adjacencies down in the event of other topology changes. This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol Data Unit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This document obsoletes RFC 5306. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5306bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5306bis/ballot/ No IPR declarations have been submitted directly on this I-D. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (YANG Data Model for OSPF Protocol) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'YANG Data Model for OSPF Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2019-07-17. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG data model that can be used to configure and manage OSPF. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NDMA) as described in RFC 8342. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc4973: OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering (Experimental - Independent Submission Editor stream) rfc1765: OSPF Database Overflow (Experimental - IETF stream) ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (OSPF Routing with Cross-Address Family Traffic Engineering Tunnels) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'OSPF Routing with Cross-Address Family Traffic Engineering Tunnels' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2019-07-11. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network, the Multiprotocol Label Switching (MPLS) TE Label Switched Paths (LSP) infrastructure may be duplicated, even if the destination IPv4 and IPv6 addresses belong to the same remote router. In order to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be computed over MPLS TE tunnels created using information propagated in another OSPF instance. This issue is solved by advertising cross- address family (X-AF) OSPF TE information. This document describes an update to RFC5786 that allows for the easy identification of a router's local X-AF IP addresses. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/ballot/ No IPR declarations have been submitted directly on this I-D. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'IS-IS Extensions for Segment Routing' to Proposed Standard (draft-ietf-isis-segment-routing-extensions-25.txt)
The IESG has approved the following document: - 'IS-IS Extensions for Segment Routing' (draft-ietf-isis-segment-routing-extensions-25.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/ Technical Summary This draft describes the necessary IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data-plane. Working Group Summary This draft has been thoroughly discussed in the WG at various stages of the document progression. The draft adoption and progress has received full support from the WG. Document Quality The proposed extensions have been implemented by 4 vendors-os/implementations. Some of the interoperability details are publicly available from EANTC. Personnel Uma Chunduri is the Document Shepherd. Alvaro Retana is the Responsible Area Director. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (IS-IS Extensions for Segment Routing) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Extensions for Segment Routing' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2019-04-17. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the necessary IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data-plane. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2232/ https://datatracker.ietf.org/ipr/2297/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'OSPFv3 Extensions for Segment Routing' to Proposed Standard (draft-ietf-ospf-ospfv3-segment-routing-extensions-23.txt)
The IESG has approved the following document: - 'OSPFv3 Extensions for Segment Routing' (draft-ietf-ospf-ospfv3-segment-routing-extensions-23.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-routing-extensions/ Technical Summary This document describes the OSPFv3 extensions for segment routing including Prefix-SID, Adjacency-SID, and LAN-Adjacency-SID. The extensions are based on RFC 8362 and RFC 7770. Working Group Summary The Working Group discussion has been dominated by the initial vendors that implemented the segment routing on OSPFv2 (Juniper, Cisco, Nokia, and Huawei). Document Quality The document has been implemented by Huawei and Nokia and is planned by other. The encoding changes have mirrored those in the OSPFv2 segment routing extensions. Personnel Acee Lindem is the Document Shepherd. Alvaro Retana is the Responsible Area Director. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'IS-IS Traffic Engineering (TE) Metric Extensions' to Proposed Standard (draft-ietf-lsr-isis-rfc7810bis-05.txt)
The IESG has approved the following document: - 'IS-IS Traffic Engineering (TE) Metric Extensions' (draft-ietf-lsr-isis-rfc7810bis-05.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc7810bis/ Technical Summary This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305) such that network-performance information can be distributed and collected in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance. Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. Working Group Summary This bis draft update to RFC7810 was created out of an errata submitted that pointed out errors in the definition of certain bandwidth related sub-TLVs. There was a quick and unanimous decision to address this error by publishing this bis update. The specific changes are outlined in the Appendix. Document Quality The RFC7810 published over two years ago has at least two known implementations. There is no change to the technical solution in this update. The updated bis draft has identical content to RFC7810 except for the changes for fixing of the error in encoding and highlighting the changes in the appendix. Personnel Ketan Talaulikar is the Document Shepherd. Alvaro Retana is the Responsible Area Director. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'IS-IS Routing with Reverse Metric' to Proposed Standard (draft-ietf-isis-reverse-metric-17.txt)
The IESG has approved the following document: - 'IS-IS Routing with Reverse Metric' (draft-ietf-isis-reverse-metric-17.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-isis-reverse-metric/ Technical Summary This document describes a mechanism to allow IS-IS routing to quickly and accurately shift traffic away from either a point-to-point or multi-access LAN interface during network maintenance or other operational events. This is accomplished by signaling adjacent IS-IS neighbors with a higher reverse metric, i.e., the metric towards the signaling IS-IS router. Working Group Summary Normal WG process. Document Quality There is vendor and operator interest in this technology. The document had a good amount of review by the WG, changes were requested and incorporated by the authors. Personnel Shepherd: Christian Hopps AD: Alvaro Retana ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (IS-IS Traffic Engineering (TE) Metric Extensions) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Traffic Engineering (TE) Metric Extensions' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-12-12. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network- performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics. This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305) such that network-performance information can be distributed and collected in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance. Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. This document obsoletes RFC 7810. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc7810bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc7810bis/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3257/ https://datatracker.ietf.org/ipr/3259/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'OSPF LLS Extensions for Local Interface ID Advertisement' to Proposed Standard (draft-ietf-ospf-lls-interface-id-09.txt)
The IESG has approved the following document: - 'OSPF LLS Extensions for Local Interface ID Advertisement' (draft-ietf-ospf-lls-interface-id-09.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-lls-interface-id/ Technical Summary This draft describes the extensions to OSPF link-local signalling (LLS) to advertise the Local Interface Identifier. Working Group Summary There was initially some contention as to whether interface ID discovery via OSPFv2 LLS was required given that the interface ID can be advertised via OSPF GMPLS TE extensions [RFC4203]. However, given that the advantages of fewer LSAs, discovery concurrent with neighbor discovery, and incompatibilities with implementations adding nodes to the TE topology, the consensus was to advance this simple mechanism. Additionally, both IS-IS and OSPFv3 have similar hello-based interface ID discovery. Document Quality This document has been a WG document for more than 1 year and has had several good reviews. The author list includes multiple vendor affiliations. Personnel Yingzhen Qu is the Document Shepherd. Alvaro Retana is the Responsible Area Director. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (OSPFv3 Extensions for Segment Routing) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'OSPFv3 Extensions for Segment Routing' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-11-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the OSPFv3 extensions required for Segment Routing. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-routing-extensions/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-routing-extensions/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2234/ https://datatracker.ietf.org/ipr/2812/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'Signaling MSD (Maximum SID Depth) using OSPF' to Proposed Standard (draft-ietf-ospf-segment-routing-msd-23.txt)
The IESG has approved the following document: - 'Signaling MSD (Maximum SID Depth) using OSPF' (draft-ietf-ospf-segment-routing-msd-23.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/ Technical Summary This document defines a way for an Open Shortest Path First (OSPF) Router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular SID stack can be supported in a given network. Working Group Summary Nothing specific to highlight; normal process. Document Quality This document has been a WG document for 1 1/2 years and has had several good reviews. Personnel Acee Lindem is the Document Shepherd. Alvaro Retana is the Responsible Area Director. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Protocol Action: 'Signaling MSD (Maximum SID Depth) using IS-IS' to Proposed Standard (draft-ietf-isis-segment-routing-msd-18.txt)
The IESG has approved the following document: - 'Signaling MSD (Maximum SID Depth) using IS-IS' (draft-ietf-isis-segment-routing-msd-18.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/ Technical Summary This document defines a way for an Intermediate System to Intermediate System (IS-IS) Router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular SID stack can be supported in a given network. Working Group Summary Nothing to highlight; normal process. Document Quality This document has been a WG document for over a year (and has existed for over 2 yars) and has been regularly revised and well reviewed. Personnel Shepherd: Christian Hopps AD: Alvaro Retana IANA Note Designated Experts for the new "IGP MSD Types" registry are: Uma Chunduri (uma.chund...@huawei.com) and Jeff Tantsura (jefftant.i...@gmail.com). ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (IS-IS Routing with Reverse Metric) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'IS-IS Routing with Reverse Metric' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-10-17. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism to allow IS-IS routing to quickly and accurately shift traffic away from either a point-to-point or multi-access LAN interface during network maintenance or other operational events. This is accomplished by signaling adjacent IS-IS neighbors with a higher reverse metric, i.e., the metric towards the signaling IS-IS router. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-isis-reverse-metric/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-isis-reverse-metric/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5443: LDP IGP Synchronization (Informational - IETF stream) ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (OSPF LLS Extensions for Local Interface ID Advertisement) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'OSPF LLS Extensions for Local Interface ID Advertisement' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-10-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Every OSPF interface is assigned an identifier, Interface ID, which uniquely identifies the interface on the router. In some cases it is useful to know the assigned Interface ID on the remote side of the adjacency (Remote Interface ID). This draft describes the extensions to OSPF link-local signalling to advertise the Local Interface Identifier. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ospf-lls-interface-id/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ospf-lls-interface-id/ballot/ No IPR declarations have been submitted directly on this I-D. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (Signaling MSD (Maximum SID Depth) using IS-IS) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Signaling MSD (Maximum SID Depth) using IS-IS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-09-12. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a way for an Intermediate System to Intermediate System (IS-IS) Router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular SID stack can be supported in a given network. This document only defines one type of MSD maximum label imposition, but defines an encoding that can support other MSD types. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3037/ https://datatracker.ietf.org/ipr/3255/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Last Call: (Signaling MSD (Maximum SID Depth) using OSPF) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Signaling MSD (Maximum SID Depth) using OSPF' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-08-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a way for an OSPF Router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular SID stack can be supported in a given network. This document defines only one type of MSD, but defines an encoding that can support other MSD types. Here the term OSPF means both OSPFv2 and OSPFv3. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3040/ https://datatracker.ietf.org/ipr/3254/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] WG Action: Formed Link State Routing (lsr)
A new IETF WG has been formed in the Routing Area. For additional information, please contact the Area Directors or the WG Chairs. Link State Routing (lsr) --- Current status: Proposed WG Chairs: Acee Lindem Christian Hopps Assigned Area Director: Alia Atlas Routing Area Directors: Alia Atlas Alvaro Retana Deborah Brungard Mailing list: Address: lsr@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/lsr Archive: https://mailarchive.ietf.org/arch/browse/lsr/ Group page: https://datatracker.ietf.org/group/lsr/ Charter: https://datatracker.ietf.org/doc/charter-ietf-lsr/ The Link-State Routing (LSR) Working Group is chartered to document current protocol implementation practices and improvements, protocol usage scenarios, maintenance and extensions of the link-state interior gateway routing protocols (IGPs) - specifically IS-IS, OSPFv2, and OSPFv3. The LSR Working Group was formed by merging the isis and ospf WGs and assigning all their existing adopted work at the time of chartering to LSR. IS-IS is an IGP specified and standardized by ISO through ISO 10589:2002 and additional RFC standards with extensions to support IP that has been deployed in the Internet for decades. For the IS-IS protocol, LSR-WG’s work is focused on IP routing, currently based on the agreement in RFC 3563 with ISO/JTC1/SC6. The LSR-WG will interact with other standards bodies that have responsibility for standardizing IS-IS. LSR-WG will continue to support Layer 2 routing (for example TRILL work) as needed. OSPFv2 [RFC 2328 and extensions], is an IGP that has been deployed in the Internet for decades. OSPFv3 [RFC5340 and extensions] provides OSPF for IPv6 and IPv4 [RFC5838] which can be delivered over IPv6 or IPv4 [RFC 7949]. The LSR Working Group will generally manage its specific work items by milestones agreed with the responsible Area Director. In addition to ongoing maintenance, the following topics are specific work-items for the WG. 1) Improve OSPF support for IPv6 and create at least parity with IPv4 functionality by adding OSPFv3 extensions using the OSPFv3 Extended LSAs. 2) Extensions needed for Segment Routing and associated architectural changes 3) YANG models for the management of IS-IS, OSPFv2, and OSPFv3 and extensions 4) Extensions for source-destination routing 5) Improvements to flooding (and other behaviors) to better support dense meshed network topologies, such as are commonly used in data centers. The Link-State Routing (LSR) Working Group will coordinate with other working groups, such as RTGWG, SPRING, MPLS, TEAS, PCE, V6OPS, and 6MAN, to understand the need for extensions and to confirm that the planned work meets the needs and is compatible with IS-IS and/or OSPF from functional, architectural and performance point of views. LSR-WG will coordinate with CCAMP, TEAS, and BIER on their extensions to the LSR IGPs as applicable to LSR protocol operation and scale. LSR-WG should coordinate with other WGs as needed. Milestones: Jul 2018 - OSPF YANG Model to IESG Jul 2018 - ISIS YANG model to IESG Jul 2018 - IS-IS Reverse Metric to IESG Jul 2018 - IS-IS Segment Routing MSD to IESG Nov 2018 - OSPFv3 SR to IESG Nov 2018 - OSPFv2 Attribute Agility Mar 2019 - OSPF Segment Routing YANG Model Mar 2019 - IS-IS Segment Routing SR YANG Model Jul 2019 - OSPFv3 Dual Stack (single instance) ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
