Distribution of Link-State and Traffic Engineering Information Using BGP
draft-ietf-idr-rfc7752bis-10
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2021-11-10
|
10 | Jeffrey Haas | : (1) What type of RFC is being requested: Proposed Standard : Why is this the proper type of RFC? Replaces RFC5575 : Is this … : (1) What type of RFC is being requested: Proposed Standard : Why is this the proper type of RFC? Replaces RFC5575 : Is this type of RFC indicated in the title page header? Yes : (2) The IESG approval announcement includes a Document Announcement Write-Up. : Please provide such a Document Announcement Write-Up. Recent examples can : be found in the "Action" announcements for approved documents. The : approval announcement contains the following sections: : : Technical Summary: In a number of environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates which it made to RFC 7752. : Working Group Summary: Work on this document primarily happened off the Working Group mail list. A substantial amount of the original content was produced in the original document, draft-ketant-idr-rfc7752bis. Refinements that happened to the draft occurred through discussions including those at IETF to address known issues in the original RFC 7752. : Was there anything in WG process that is worth noting? Participation was light, but the participants were deeply versed in the technology under consideration. : Document Quality: The document is of high quality. Since this is a -bis document, the original content had been through the RFC process and started in good shape. The new text and clarifications that were introduced in each revision were well considered and cleanly worded. : Are there existing implementations of the protocol? https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-RFC7752bis%20implementations%20 : : Have a significant number of vendors indicated their plan to implement the : specification? RFC7752 is widely deployed. This draft corrects the specification for things learned from deployment. : Personnel: : Document Shepherd: Jeffrey Haas <jhaas@pfrc.org> : Area Director: Alvaro Retana : (3) Briefly describe the review of this document that was performed by the : Document Shepherd. A thorough review of the document was done. There were some small number of nits to be resolved. During review, three error handling considerations were highlighted that were not covered in the draft: - NLRI keying consistency when optional TLVs can be used. - BGP-LS Attribute consistency created by multiple BGP-LS Producers. - A desire for more discussion about error handling procedures for BGP-LS Consumers in the face of syntactically valid but semantically invalid protocol state. This discussion resulted in small updates to the document to address the raised points. : (4) Does the document Shepherd have any concerns about the depth or breadth of : the reviews that have been performed? The changes to the document are straight-forward alterations providing clarity vs. clearly traceable requirements for the covered IGP state in most cases. In the other cases, protocol ambiguities are addressed that are mostly based in BGP route propagation semantics. : (5) Do portions of the document need review from a particular or from broader : perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, ; or internationalization? If so, describe the review that took place. No. The changes are largely either clarifications with clear reference to the source IGP material, or localized to BGP impacts of the protocol. : (6) Describe any specific concerns or issues that the Document Shepherd has : with this document that the Responsible Area Director and/or the IESG : should be aware of? No. : (7) Has each author confirmed that any and all appropriate IPR disclosures : required for full conformance with the provisions of BCP 78 and BCP 79 : have already been filed. If not, explain why? Editor: K. Talaulikar, Cisco: Cisco Systems India Email: ketant@cisco.com https://mailarchive.ietf.org/arch/msg/idr/xp-9imj9pabQdgb6Gly0otv8MNE/ Co-authors: Hannes Gredler Rtbrick Email: hannes@rtbrick.com https://mailarchive.ietf.org/arch/msg/idr/Vk3mubVmkXHVbtAsNVlzys_EiV0/ Jan Medved Cisco Systems Inc. USA Email: jmedved@cisco.com https://mailarchive.ietf.org/arch/msg/idr/Rq3f4I7m-paP-qait53APbEWIYE/ Stefano Previdi Huawei Technologies Italy Email: stefano@previdi.net https://mailarchive.ietf.org/arch/msg/idr/2-8I787YxhuSZpv_MjBhbGK-JcQ/ Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk https://mailarchive.ietf.org/arch/msg/idr/Na0eFQFG9S6oxYiWmV_6l5d4Boo/ Saikat Ray Individual USA Email: raysaikat@gmail.com https://mailarchive.ietf.org/arch/msg/idr/q4q_C8wViQH2JolotJHlDXCQhG4/ : (8) Has an IPR disclosure been filed that references this document? If so, : summarize any WG discussion and conclusion regarding the IPR disclosures. Prior IPR vs. RFC 7752 was disclosed by a third-party: https://datatracker.ietf.org/ipr/3623/ Juniper Networks provided the overlapping first-party disclosure at a later date. : (9) How solid is the WG consensus behind this document? Does it represent the : strong concurrence of a few individuals, with others being silent, or does : the WG as a whole understand and agree with it? Being a technology heavily focused on IGP and TE state, participation in the Working Group Last Call was low. Of those pariticipants, several individuals who have heavy focus on those technologies supported it. This included one of the LSR Working Group chairs. : (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No. : (11) Identify any ID nits the Document Shepherd has found in this document. : (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts : Checklist). Boilerplate checks are not enough; this check needs to be thorough. No substantive nits. : (12) Describe how the document meets any required formal review criteria, such : as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No formal review : (13) Have all references within this document been identified as either normative or informative? Yes. : (14) Are there normative references to documents that are not ready for : advancement or are otherwise in an unclear state? If such normative : references exist, what is the plan for their completion? No. : (15) Are there downward normative references references (see RFC 3967)? No. : (16) Will publication of this document change the status of any existing RFCs? Obsolete RFC 7752 and RFC 9029. : Are those RFCs listed on the title page header, listed in the abstract, : and discussed in the introduction? Yes. : (17) Describe the Document Shepherd's review of the IANA considerations : section, especially with regard to its consistency with the body of the : document. Confirm that all protocol extensions that the document makes : are associated with the appropriate reservations in IANA registries. : Confirm that any referenced IANA registries have been clearly identified. : Confirm that newly created IANA registries include a detailed : specification of the initial contents for the registry, that allocations : procedures for future registrations are defined, and a reasonable name : for the new registry has been suggested (see RFC 8126). A review of all code points vs. registries was completed. Three new registries were identified that were not previously created via RFC 7752: - 6.1.4. BGP-LS Node Flags Registry - 6.1.5. BGP-LS MPLS Protocol Mask Registry - 6.1.6. BGP-LS IGP Prefix Flags Registry Each of these registries have a policy of RFC Required. : (18) List any new IANA registries that require Expert Review for future : allocations. Provide any public guidance that the IESG would find useful : in selecting the IANA Experts for these new registries. None. : (19) Describe reviews and automated checks performed by the Document Shepherd : to validate sections of the document written in a formal language, such : as XML code, BNF rules, MIB definitions, YANG modules, etc. N/A. : (20) If the document contains a YANG module, has the module been checked with : any of the recommended validation tools : (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and ; formatting validation? If there are any resulting errors or warnings, : what is the justification for not fixing them at this time? Does the YANG : module comply with the Network Management Datastore Architecture (NMDA) : as specified in RFC8342? N/A. There is currently no YANG module for BGP-LS. |
|
2021-11-10
|
10 | Jeffrey Haas | Responsible AD changed to Alvaro Retana |
|
2021-11-10
|
10 | Jeffrey Haas | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
|
2021-11-10
|
10 | Jeffrey Haas | IESG state changed to Publication Requested from I-D Exists |
|
2021-11-10
|
10 | Jeffrey Haas | IESG process started in state Publication Requested |
|
2021-11-10
|
10 | Jeffrey Haas | Changed consensus to Yes from Unknown |
|
2021-11-10
|
10 | Jeffrey Haas | Intended Status changed to Proposed Standard from None |
|
2021-11-10
|
10 | Jeffrey Haas | Tag Doc Shepherd Follow-up Underway cleared. |
|
2021-11-10
|
10 | Jeffrey Haas | : (1) What type of RFC is being requested: Proposed Standard : Why is this the proper type of RFC? Replaces RFC5575 : Is this … : (1) What type of RFC is being requested: Proposed Standard : Why is this the proper type of RFC? Replaces RFC5575 : Is this type of RFC indicated in the title page header? Yes : (2) The IESG approval announcement includes a Document Announcement Write-Up. : Please provide such a Document Announcement Write-Up. Recent examples can : be found in the "Action" announcements for approved documents. The : approval announcement contains the following sections: : : Technical Summary: In a number of environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates which it made to RFC 7752. : Working Group Summary: Work on this document primarily happened off the Working Group mail list. A substantial amount of the original content was produced in the original document, draft-ketant-idr-rfc7752bis. Refinements that happened to the draft occurred through discussions including those at IETF to address known issues in the original RFC 7752. : Was there anything in WG process that is worth noting? Participation was light, but the participants were deeply versed in the technology under consideration. : Document Quality: The document is of high quality. Since this is a -bis document, the original content had been through the RFC process and started in good shape. The new text and clarifications that were introduced in each revision were well considered and cleanly worded. : Are there existing implementations of the protocol? https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-RFC7752bis%20implementations%20 : : Have a significant number of vendors indicated their plan to implement the : specification? RFC7752 is widely deployed. This draft corrects the specification for things learned from deployment. : Personnel: : Document Shepherd: Jeffrey Haas <jhaas@pfrc.org> : Area Director: Alvaro Retana : (3) Briefly describe the review of this document that was performed by the : Document Shepherd. A thorough review of the document was done. There were some small number of nits to be resolved. During review, three error handling considerations were highlighted that were not covered in the draft: - NLRI keying consistency when optional TLVs can be used. - BGP-LS Attribute consistency created by multiple BGP-LS Producers. - A desire for more discussion about error handling procedures for BGP-LS Consumers in the face of syntactically valid but semantically invalid protocol state. This discussion resulted in small updates to the document to address the raised points. : (4) Does the document Shepherd have any concerns about the depth or breadth of : the reviews that have been performed? The changes to the document are straight-forward alterations providing clarity vs. clearly traceable requirements for the covered IGP state in most cases. In the other cases, protocol ambiguities are addressed that are mostly based in BGP route propagation semantics. : (5) Do portions of the document need review from a particular or from broader : perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, ; or internationalization? If so, describe the review that took place. No. The changes are largely either clarifications with clear reference to the source IGP material, or localized to BGP impacts of the protocol. : (6) Describe any specific concerns or issues that the Document Shepherd has : with this document that the Responsible Area Director and/or the IESG : should be aware of? No. : (7) Has each author confirmed that any and all appropriate IPR disclosures : required for full conformance with the provisions of BCP 78 and BCP 79 : have already been filed. If not, explain why? Editor: K. Talaulikar, Cisco: Cisco Systems India Email: ketant@cisco.com https://mailarchive.ietf.org/arch/msg/idr/xp-9imj9pabQdgb6Gly0otv8MNE/ Co-authors: Hannes Gredler Rtbrick Email: hannes@rtbrick.com https://mailarchive.ietf.org/arch/msg/idr/Vk3mubVmkXHVbtAsNVlzys_EiV0/ Jan Medved Cisco Systems Inc. USA Email: jmedved@cisco.com https://mailarchive.ietf.org/arch/msg/idr/Rq3f4I7m-paP-qait53APbEWIYE/ Stefano Previdi Huawei Technologies Italy Email: stefano@previdi.net https://mailarchive.ietf.org/arch/msg/idr/2-8I787YxhuSZpv_MjBhbGK-JcQ/ Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk https://mailarchive.ietf.org/arch/msg/idr/Na0eFQFG9S6oxYiWmV_6l5d4Boo/ Saikat Ray Individual USA Email: raysaikat@gmail.com https://mailarchive.ietf.org/arch/msg/idr/q4q_C8wViQH2JolotJHlDXCQhG4/ : (8) Has an IPR disclosure been filed that references this document? If so, : summarize any WG discussion and conclusion regarding the IPR disclosures. Prior IPR vs. RFC 7752 was disclosed by a third-party: https://datatracker.ietf.org/ipr/3623/ Juniper Networks provided the overlapping first-party disclosure at a later date. : (9) How solid is the WG consensus behind this document? Does it represent the : strong concurrence of a few individuals, with others being silent, or does : the WG as a whole understand and agree with it? Being a technology heavily focused on IGP and TE state, participation in the Working Group Last Call was low. Of those pariticipants, several individuals who have heavy focus on those technologies supported it. This included one of the LSR Working Group chairs. : (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No. : (11) Identify any ID nits the Document Shepherd has found in this document. : (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts : Checklist). Boilerplate checks are not enough; this check needs to be thorough. No substantive nits. : (12) Describe how the document meets any required formal review criteria, such : as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No formal review : (13) Have all references within this document been identified as either normative or informative? Yes. : (14) Are there normative references to documents that are not ready for : advancement or are otherwise in an unclear state? If such normative : references exist, what is the plan for their completion? No. : (15) Are there downward normative references references (see RFC 3967)? No. : (16) Will publication of this document change the status of any existing RFCs? Obsolete RFC 7752 and RFC 9029. : Are those RFCs listed on the title page header, listed in the abstract, : and discussed in the introduction? Yes. : (17) Describe the Document Shepherd's review of the IANA considerations : section, especially with regard to its consistency with the body of the : document. Confirm that all protocol extensions that the document makes : are associated with the appropriate reservations in IANA registries. : Confirm that any referenced IANA registries have been clearly identified. : Confirm that newly created IANA registries include a detailed : specification of the initial contents for the registry, that allocations : procedures for future registrations are defined, and a reasonable name : for the new registry has been suggested (see RFC 8126). A review of all code points vs. registries was completed. Three new registries were identified that were not previously created via RFC 7752: - 6.1.4. BGP-LS Node Flags Registry - 6.1.5. BGP-LS MPLS Protocol Mask Registry - 6.1.6. BGP-LS IGP Prefix Flags Registry Each of these registries have a policy of RFC Required. : (18) List any new IANA registries that require Expert Review for future : allocations. Provide any public guidance that the IESG would find useful : in selecting the IANA Experts for these new registries. None. : (19) Describe reviews and automated checks performed by the Document Shepherd : to validate sections of the document written in a formal language, such : as XML code, BNF rules, MIB definitions, YANG modules, etc. N/A. : (20) If the document contains a YANG module, has the module been checked with : any of the recommended validation tools : (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and ; formatting validation? If there are any resulting errors or warnings, : what is the justification for not fixing them at this time? Does the YANG : module comply with the Network Management Datastore Architecture (NMDA) : as specified in RFC8342? N/A. There is currently no YANG module for BGP-LS. |
|
2021-11-10
|
10 | Ketan Talaulikar | New version available: draft-ietf-idr-rfc7752bis-10.txt |
|
2021-11-10
|
10 | (System) | New version accepted (logged-in submitter: Ketan Talaulikar) |
|
2021-11-10
|
10 | Ketan Talaulikar | Uploaded new revision |
|
2021-10-25
|
09 | Ketan Talaulikar | New version available: draft-ietf-idr-rfc7752bis-09.txt |
|
2021-10-25
|
09 | (System) | New version accepted (logged-in submitter: Ketan Talaulikar) |
|
2021-10-25
|
09 | Ketan Talaulikar | Uploaded new revision |
|
2021-09-15
|
Jasmine Magallanes | Posted related IPR disclosure Juniper Networks, Inc.'s Statement about IPR related to draft-ietf-idr-rfc7752bis | |
|
2021-08-27
|
08 | Jeffrey Haas | : (1) What type of RFC is being requested: Proposed Standard : Why is this the proper type of RFC? Replaces RFC5575 : Is this … : (1) What type of RFC is being requested: Proposed Standard : Why is this the proper type of RFC? Replaces RFC5575 : Is this type of RFC indicated in the title page header? Yes : (2) The IESG approval announcement includes a Document Announcement Write-Up. : Please provide such a Document Announcement Write-Up. Recent examples can : be found in the "Action" announcements for approved documents. The : approval announcement contains the following sections: : : Technical Summary: In a number of environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates which it made to RFC 7752. : Working Group Summary: Work on this document primarily happened off the Working Group mail list. A substantial amount of the original content was produced in the original document, draft-ketant-idr-rfc7752bis. Refinements that happened to the draft occurred through discussions including those at IETF to address known issues in the original RFC 7752. : Was there anything in WG process that is worth noting? Participation was light, but the participants were deeply versed in the technology under consideration. : Document Quality: The document is of high quality. Since this is a -bis document, the original content had been through the RFC process and started in good shape. The new text and clarifications that were introduced in each revision were well considered and cleanly worded. : Are there existing implementations of the protocol? https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-RFC7752bis%20implementations%20 : : Have a significant number of vendors indicated their plan to implement the : specification? RFC7752 is widely deployed. This draft corrects the specification for things learned from deployment. : Personnel: : Document Shepherd: Jeffrey Haas <jhaas@pfrc.org> : Area Director: Alvaro Retana : (3) Briefly describe the review of this document that was performed by the : Document Shepherd. A thorough review of the document was done. There were some small number of nits to be resolved. During review, three error handling considerations were highlighted that were not covered in the draft: - NLRI keying consistency when optional TLVs can be used. - BGP-LS Attribute consistency created by multiple BGP-LS Producers. - A desire for more discussion about error handling procedures for BGP-LS Consumers in the face of syntactically valid but semantically invalid protocol state. : (4) Does the document Shepherd have any concerns about the depth or breadth of : the reviews that have been performed? The changes to the document are straight-forward alterations providing clarity vs. clearly traceable requirements for the covered IGP state in most cases. In the other cases, protocol ambiguities are addressed that are mostly based in BGP route propagation semantics. : (5) Do portions of the document need review from a particular or from broader : perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, ; or internationalization? If so, describe the review that took place. No. The changes are largely either clarifications with clear reference to the source IGP material, or localized to BGP impacts of the protocol. : (6) Describe any specific concerns or issues that the Document Shepherd has : with this document that the Responsible Area Director and/or the IESG : should be aware of? No. : (7) Has each author confirmed that any and all appropriate IPR disclosures : required for full conformance with the provisions of BCP 78 and BCP 79 : have already been filed. If not, explain why? Editor: K. Talaulikar, Cisco: Cisco Systems India Email: ketant@cisco.com https://mailarchive.ietf.org/arch/msg/idr/xp-9imj9pabQdgb6Gly0otv8MNE/ Co-authors: Hannes Gredler Rtbrick Email: hannes@rtbrick.com https://mailarchive.ietf.org/arch/msg/idr/Vk3mubVmkXHVbtAsNVlzys_EiV0/ Jan Medved Cisco Systems Inc. USA Email: jmedved@cisco.com https://mailarchive.ietf.org/arch/msg/idr/Rq3f4I7m-paP-qait53APbEWIYE/ Stefano Previdi Huawei Technologies Italy Email: stefano@previdi.net https://mailarchive.ietf.org/arch/msg/idr/2-8I787YxhuSZpv_MjBhbGK-JcQ/ Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk https://mailarchive.ietf.org/arch/msg/idr/Na0eFQFG9S6oxYiWmV_6l5d4Boo/ Saikat Ray Individual USA Email: raysaikat@gmail.com https://mailarchive.ietf.org/arch/msg/idr/q4q_C8wViQH2JolotJHlDXCQhG4/ : (8) Has an IPR disclosure been filed that references this document? If so, : summarize any WG discussion and conclusion regarding the IPR disclosures. Prior IPR vs. RFC 7752 was disclosed by a third-party: https://datatracker.ietf.org/ipr/3623/ Junper Networks has been contacted to see if they'll add an official first-party disclosure. : (9) How solid is the WG consensus behind this document? Does it represent the : strong concurrence of a few individuals, with others being silent, or does : the WG as a whole understand and agree with it? Being a technology heavily focused on IGP and TE state, participation in the Working Group Last Call was low. Of those pariticipants, several individuals who have heavy focus on those technologies supported it. This included one of the LSR Working Group chairs. : (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No. : (11) Identify any ID nits the Document Shepherd has found in this document. : (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts : Checklist). Boilerplate checks are not enough; this check needs to be thorough. No substantive nits. : (12) Describe how the document meets any required formal review criteria, such : as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No formal review : (13) Have all references within this document been identified as either normative or informative? Yes. : (14) Are there normative references to documents that are not ready for : advancement or are otherwise in an unclear state? If such normative : references exist, what is the plan for their completion? No. : (15) Are there downward normative references references (see RFC 3967)? No. : (16) Will publication of this document change the status of any existing RFCs? Obsolete RFC 7752 and RFC 9029. : Are those RFCs listed on the title page header, listed in the abstract, : and discussed in the introduction? Yes. : (17) Describe the Document Shepherd's review of the IANA considerations : section, especially with regard to its consistency with the body of the : document. Confirm that all protocol extensions that the document makes : are associated with the appropriate reservations in IANA registries. : Confirm that any referenced IANA registries have been clearly identified. : Confirm that newly created IANA registries include a detailed : specification of the initial contents for the registry, that allocations : procedures for future registrations are defined, and a reasonable name : for the new registry has been suggested (see RFC 8126). A review of all code points vs. registries was completed. Three new registries were identified that were not previously created via RFC 7752: - 6.1.4. BGP-LS Node Flags Registry - 6.1.5. BGP-LS MPLS Protocol Mask Registry - 6.1.6. BGP-LS IGP Prefix Flags Registry Each of these registries have a policy of RFC Required. : (18) List any new IANA registries that require Expert Review for future : allocations. Provide any public guidance that the IESG would find useful : in selecting the IANA Experts for these new registries. None. : (19) Describe reviews and automated checks performed by the Document Shepherd : to validate sections of the document written in a formal language, such : as XML code, BNF rules, MIB definitions, YANG modules, etc. N/A. : (20) If the document contains a YANG module, has the module been checked with : any of the recommended validation tools : (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and ; formatting validation? If there are any resulting errors or warnings, : what is the justification for not fixing them at this time? Does the YANG : module comply with the Network Management Datastore Architecture (NMDA) : as specified in RFC8342? N/A. There is currently no YANG module for BGP-LS. |
|
2021-08-06
|
08 | Susan Hares | Notification list changed to shares@ndzh.com, jhaas@pfrc.org from shares@ndzh.com because the document shepherd was set |
|
2021-08-06
|
08 | Susan Hares | Document shepherd changed to Jeffrey Haas |
|
2021-08-06
|
08 | Susan Hares | Tag Doc Shepherd Follow-up Underway set. |
|
2021-08-06
|
08 | Susan Hares | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
|
2021-07-26
|
08 | Ketan Talaulikar | New version available: draft-ietf-idr-rfc7752bis-08.txt |
|
2021-07-26
|
08 | (System) | New version accepted (logged-in submitter: Ketan Talaulikar) |
|
2021-07-26
|
08 | Ketan Talaulikar | Uploaded new revision |
|
2021-07-09
|
07 | Susan Hares | RFC 4858 Shepherd Write-Up (11/1/2019) This version is dated 1 November 2019. (1) What type of RFC is being requested: Proposed Standard Why is this … RFC 4858 Shepherd Write-Up (11/1/2019) This version is dated 1 November 2019. (1) What type of RFC is being requested: Proposed Standard Why is this the proper type of RFC? Replaces RFC5575 Is this type of RFC indicated in the title page header? Yes (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: In a number of environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates which it made to RFC 7752. Working Group Summary: (TBD) Was there anything in WG process that is worth noting? [TBD] Document Quality: [TBd] Are there existing implementations of the protocol? https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-RFC7752bis%20implementations%20 Have a significant number of vendors indicated their plan to implement the specification? RFC7752 is widely deployed. This draft corrects the specification for things learne din deployment. RTG-DIR: OPS Personnel: Document Shepherd: (All IDR chairs) AD: Alvaro Retana (3) Briefly describe the review of this document that was performed by the Document Shepherd. (TBd) (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? (TBD) (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. (TBD) (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? (TBD) (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Editor: K. Talaulikar, Cisco: Cisco Systems India Email: ketant@cisco.com https://mailarchive.ietf.org/arch/msg/idr/xp-9imj9pabQdgb6Gly0otv8MNE/ Co-authors: Hannes Gredler Rtbrick Email: hannes@rtbrick.com https://mailarchive.ietf.org/arch/msg/idr/Vk3mubVmkXHVbtAsNVlzys_EiV0/ Jan Medved Cisco Systems Inc. USA Email: jmedved@cisco.com https://mailarchive.ietf.org/arch/msg/idr/Rq3f4I7m-paP-qait53APbEWIYE/ Stefano Previdi Huawei Technologies Italy Email: stefano@previdi.net https://mailarchive.ietf.org/arch/msg/idr/2-8I787YxhuSZpv_MjBhbGK-JcQ/ Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk https://mailarchive.ietf.org/arch/msg/idr/Na0eFQFG9S6oxYiWmV_6l5d4Boo/ Saikat Ray Individual USA Email: raysaikat@gmail.com https://mailarchive.ietf.org/arch/msg/idr/q4q_C8wViQH2JolotJHlDXCQhG4/ (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. https://datatracker.ietf.org/ipr/3623/ 3rd party IPR mentioned in call (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? (TBD) (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? (TBD) (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. (TBD) (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No formal review (13) Have all references within this document been identified as either normative or informative? (TBD) (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? (TBD) (15) Are there downward normative references references (see RFC 3967)? (TBD) (16) Will publication of this document change the status of any existing RFCs? Obsolete RFC7752 Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? |
|
2021-06-21
|
07 | Ketan Talaulikar | New version available: draft-ietf-idr-rfc7752bis-07.txt |
|
2021-06-21
|
07 | (System) | New version accepted (logged-in submitter: Ketan Talaulikar) |
|
2021-06-21
|
07 | Ketan Talaulikar | Uploaded new revision |
|
2021-06-21
|
06 | Susan Hares | 2 weeks IPR call and Shepherd review (all IDR chairs will review) 2 weeks WG LC |
|
2021-06-21
|
06 | Susan Hares | IETF WG state changed to In WG Last Call from WG Document |
|
2021-06-21
|
06 | Susan Hares | Notification list changed to shares@ndzh.com because the document shepherd was set |
|
2021-06-21
|
06 | Susan Hares | Document shepherd changed to Susan Hares |
|
2021-05-02
|
06 | Ketan Talaulikar | New version available: draft-ietf-idr-rfc7752bis-06.txt |
|
2021-05-02
|
06 | (System) | New version accepted (logged-in submitter: Ketan Talaulikar) |
|
2021-05-02
|
06 | Ketan Talaulikar | Uploaded new revision |
|
2020-11-02
|
05 | Ketan Talaulikar | New version available: draft-ietf-idr-rfc7752bis-05.txt |
|
2020-11-02
|
05 | (System) | New version accepted (logged-in submitter: Ketan Talaulikar) |
|
2020-11-02
|
05 | Ketan Talaulikar | Uploaded new revision |
|
2020-09-04
|
04 | Ketan Talaulikar | New version available: draft-ietf-idr-rfc7752bis-04.txt |
|
2020-09-04
|
04 | (System) | New version accepted (logged-in submitter: Ketan Talaulikar) |
|
2020-09-04
|
04 | Ketan Talaulikar | Uploaded new revision |
|
2020-03-05
|
03 | Ketan Talaulikar | New version available: draft-ietf-idr-rfc7752bis-03.txt |
|
2020-03-05
|
03 | (System) | New version approved |
|
2020-03-05
|
03 | (System) | Request for posting confirmation emailed to previous authors: Ketan Talaulikar <ketant@cisco.com> |
|
2020-03-05
|
03 | Ketan Talaulikar | Uploaded new revision |
|
2019-11-01
|
02 | Ketan Talaulikar | New version available: draft-ietf-idr-rfc7752bis-02.txt |
|
2019-11-01
|
02 | (System) | New version approved |
|
2019-11-01
|
02 | (System) | Request for posting confirmation emailed to previous authors: Ketan Talaulikar <ketant@cisco.com> |
|
2019-11-01
|
02 | Ketan Talaulikar | Uploaded new revision |
|
2019-09-14
|
01 | Ketan Talaulikar | New version available: draft-ietf-idr-rfc7752bis-01.txt |
|
2019-09-14
|
01 | (System) | New version approved |
|
2019-09-14
|
01 | (System) | Request for posting confirmation emailed to previous authors: Adrian Farrel <adrian@olddog.co.uk>, idr-chairs@ietf.org, Saikat Ray <raysaikat@gmail.com>, Ketan Talaulikar <ketant@cisco.com>, … Request for posting confirmation emailed to previous authors: Adrian Farrel <adrian@olddog.co.uk>, idr-chairs@ietf.org, Saikat Ray <raysaikat@gmail.com>, Ketan Talaulikar <ketant@cisco.com>, Hannes Gredler <hannes@rtbrick.com>, Jan Medved <jmedved@cisco.com>, Stefano Previdi <stefano@previdi.net> |
|
2019-09-14
|
01 | Ketan Talaulikar | Uploaded new revision |
|
2019-09-05
|
00 | Susan Hares | This document now replaces draft-ketant-idr-rfc7752bis instead of None |
|
2019-09-05
|
00 | Ketan Talaulikar | New version available: draft-ietf-idr-rfc7752bis-00.txt |
|
2019-09-05
|
00 | (System) | WG -00 approved |
|
2019-09-05
|
00 | Ketan Talaulikar | Set submitter to "Ketan Talaulikar <ketant@cisco.com>", replaces to draft-ketant-idr-rfc7752bis and sent approval email to group chairs: idr-chairs@ietf.org |
|
2019-09-05
|
00 | Ketan Talaulikar | Uploaded new revision |