Skip to main content

BGP Prefix Independent Convergence
draft-ietf-rtgwg-bgp-pic-20

Revision differences

Document history

Date Rev. By Action
2024-01-26
20 Gunter Van de Velde Request closed, assignment withdrawn: Carlos Martínez Last Call OPSDIR review
2024-01-26
20 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2023-10-01
20 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-20.txt
2023-10-01
20 (System) New version approved
2023-10-01
20 (System) Request for posting confirmation emailed to previous authors: Ahmed Bashandy , Clarence Filsfils , Prodosh Mohapatra
2023-10-01
20 Ahmed Bashandy Uploaded new revision
2023-04-24
19 (System) Changed action holders to Alvaro Retana (IESG state changed)
2023-04-24
19 Jim Guichard IESG state changed to I-D Exists from Dead
2023-04-01
19 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-19.txt
2023-04-01
19 (System) New version approved
2023-04-01
19 (System) Request for posting confirmation emailed to previous authors: Ahmed Bashandy , Clarence Filsfils , Prodosh Mohapatra
2023-04-01
19 Ahmed Bashandy Uploaded new revision
2023-03-27
18 (System) Document has expired
2023-03-27
18 (System) IESG state changed to Dead from AD is watching
2023-03-26
18 Alvaro Retana Removed all action holders
2023-03-26
18 Alvaro Retana Tag Revised I-D Needed - Issue raised by AD set.
2023-03-26
18 Alvaro Retana IETF WG state changed to WG Document from Submitted to IESG for Publication
2023-03-26
18 Alvaro Retana
My AD term is coming to an end, and this document hasn't been revised based on the review I provided almost 8 months ago.  After …
My AD term is coming to an end, and this document hasn't been revised based on the review I provided almost 8 months ago.  After consulting with the new responsible AD, we decided to return this draft to the WG.
2023-03-26
18 (System) Changed action holders to Alvaro Retana (IESG state changed)
2023-03-26
18 Alvaro Retana IESG state changed to AD is watching from AD Evaluation::Revised I-D Needed
2023-02-23
18 Alvaro Retana Changed action holders to Clarence Filsfils, Ahmed Bashandy, Prodosh Mohapatra
2022-08-02
18 Alvaro Retana Notification list changed to Yingzhen Qu <yingzhen.ietf@gmail.com>, aretana.ietf@gmail.com from Yingzhen Qu <yingzhen.ietf@gmail.com>
2022-08-02
18 Alvaro Retana === AD review of draft-ietf-rtgwg-bgp-pic-18 ===
https://mailarchive.ietf.org/arch/msg/rtgwg/XwJ74D29CNhmlJyl-ZnSOCdqR8s/
2022-08-02
18 (System) Changed action holders to Clarence Filsfils, Alvaro Retana, Ahmed Bashandy, Prodosh Mohapatra (IESG state changed)
2022-08-02
18 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2022-07-19
18 Alvaro Retana Changed consensus to Yes from Unknown
2022-07-19
18 (System) Changed action holders to Alvaro Retana (IESG state changed)
2022-07-19
18 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2022-04-09
18 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-18.txt
2022-04-09
18 (System) New version approved
2022-04-09
18 (System) Request for posting confirmation emailed to previous authors: Ahmed Bashandy , Clarence Filsfils , Prodosh Mohapatra
2022-04-09
18 Ahmed Bashandy Uploaded new revision
2021-12-29
17 Bernie Volz Closed request for Last Call review by INTDIR with state 'Overtaken by Events'
2021-10-16
17 Yingzhen Qu
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      An Informational Track RFC is being requested and is indicated in the
      title page header.

(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:

      This informational document is proposing a forwarding plane using
      multi-level forwarding chains with maximal sharing of forwarding
      objects. In case of failure, it can reroute a large number of
      destinations by modifying a small number of objects, and traffic
      can be re-routed to ECMP or pre-calculated backup paths in a timeframe
      that does not depend on the number of BGP prefixes.

Working Group Summary:

      During WG adoption call, it’s been agreed that this document is useful,
      and there are mature implementations.

Document Quality:

      This document has been a WG document for 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.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

    The document shepherd has reviewed the document and followed the discussion on the RTGWG mailing list.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(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.

(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? For example, perhaps he or she is
    uncomfortable with certain parts of the document, or has concerns
    whether there really is a need for it. In any event, if the WG has
    discussed those issues and has indicated that it still wishes to
    advance the document, detail those concerns here.

      None.

(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?

    Yes.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.
   
    There is an IPR disclosure referencing this document:
    https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-rtgwg-bgp-pic

    The IPR disclosure was sent to the WG, and there was no concerns raised.

(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?

    There was WG consensus to publish this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      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.

      None.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(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)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  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.

      No.

(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 5226).
 
    Not applicable. No IANA registry needed.

(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.

      No 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, etc.

      Not applicable.
2021-10-16
17 Yingzhen Qu Responsible AD changed to Alvaro Retana
2021-10-16
17 Yingzhen Qu IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2021-10-16
17 Yingzhen Qu IESG state changed to Publication Requested from I-D Exists
2021-10-16
17 Yingzhen Qu IESG process started in state Publication Requested
2021-10-15
17 Yingzhen Qu IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2021-10-15
17 Yingzhen Qu
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      An Informational Track RFC is being requested and is indicated in the
      title page header.

(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:

      This informational document is proposing a forwarding plane using
      multi-level forwarding chains with maximal sharing of forwarding
      objects. In case of failure, it can reroute a large number of
      destinations by modifying a small number of objects, and traffic
      can be re-routed to ECMP or pre-calculated backup paths in a timeframe
      that does not depend on the number of BGP prefixes.

Working Group Summary:

      During WG adoption call, it’s been agreed that this document is useful,
      and there are mature implementations.

Document Quality:

      This document has been a WG document for 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.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

    The document shepherd has reviewed the document and followed the discussion on the RTGWG mailing list.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(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.

(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? For example, perhaps he or she is
    uncomfortable with certain parts of the document, or has concerns
    whether there really is a need for it. In any event, if the WG has
    discussed those issues and has indicated that it still wishes to
    advance the document, detail those concerns here.

      None.

(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?

    Yes.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.
   
    There is an IPR disclosure referencing this document:
    https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-rtgwg-bgp-pic

    The IPR disclosure was sent to the WG, and there was no concerns raised.

(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?

    There was WG consensus to publish this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      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.

      None.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(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)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  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.

      No.

(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 5226).
 
    Not applicable. No IANA registry needed.

(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.

      No 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, etc.

      Not applicable.
2021-10-13
17 Carlos Jesús Bernardos Assignment of request for Last Call review by INTDIR to Ron Bonica was marked no-response
2021-10-13
17 Carlos Jesús Bernardos Assignment of request for Last Call review by INTDIR to Ted Lemon was marked no-response
2021-10-12
17 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-17.txt
2021-10-12
17 (System) New version accepted (logged-in submitter: Ahmed Bashandy)
2021-10-12
17 Ahmed Bashandy Uploaded new revision
2021-09-26
16 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-16.txt
2021-09-26
16 (System) New version accepted (logged-in submitter: Ahmed Bashandy)
2021-09-26
16 Ahmed Bashandy Uploaded new revision
2021-08-23
15 Yingzhen Qu
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      An Informational Track RFC is being requested and is indicated in the
      title page header.

(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:

      This informational document is proposing a forwarding plane using
      multi-level forwarding chains with maximal sharing of forwarding
      objects. In case of failure, it can reroute a large number of
      destinations by modifying a small number of objects, and traffic
      can be re-routed to ECMP or pre-calculated backup paths in a timeframe
      that does not depend on the number of BGP prefixes.

Working Group Summary:

      During WG adoption call, it’s been agreed that this document is useful,
      and there are mature implementations.

Document Quality:

      This document has been a WG document for 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.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

    The document shepherd has reviewed the document and followed the discussion on the RTGWG mailing list.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(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.

(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? For example, perhaps he or she is
    uncomfortable with certain parts of the document, or has concerns
    whether there really is a need for it. In any event, if the WG has
    discussed those issues and has indicated that it still wishes to
    advance the document, detail those concerns here.

      None.

(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?

    Yes.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.
   
    There is an IPR disclosure referencing this document:
    https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-rtgwg-bgp-pic

    The IPR disclosure was sent to the WG, and there was no concerns raised.

(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?

    There was WG consensus to publish this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      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.

      One nits identified by indicts needs to be resolved. Email sent to the authors.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(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)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  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.

      No.

(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 5226).
 
    Not applicable. No IANA registry needed.

(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.

      No 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, etc.

      Not applicable.
2021-08-20
15 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-15.txt
2021-08-20
15 (System) New version approved
2021-08-20
15 (System) Request for posting confirmation emailed to previous authors: Ahmed Bashandy , Clarence Filsfils , Prodosh Mohapatra
2021-08-20
15 Ahmed Bashandy Uploaded new revision
2021-08-15
14 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-14.txt
2021-08-15
14 (System) New version approved
2021-08-15
14 (System) Request for posting confirmation emailed to previous authors: Ahmed Bashandy , Clarence Filsfils , Prodosh Mohapatra
2021-08-15
14 Ahmed Bashandy Uploaded new revision
2021-05-10
13 Carlos Jesús Bernardos Request for Last Call review by INTDIR is assigned to Ron Bonica
2021-05-10
13 Carlos Jesús Bernardos Request for Last Call review by INTDIR is assigned to Ron Bonica
2021-04-28
13 Carlos Jesús Bernardos Request for Last Call review by INTDIR is assigned to Ted Lemon
2021-04-28
13 Carlos Jesús Bernardos Request for Last Call review by INTDIR is assigned to Ted Lemon
2021-03-29
13 Francesca Palombini Closed request for Last Call review by ARTART with state 'Overtaken by Events'
2021-02-14
13 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-13.txt
2021-02-14
13 (System) New version approved
2021-02-14
13 (System) Request for posting confirmation emailed to previous authors: Ahmed Bashandy , Clarence Filsfils , Prodosh Mohapatra
2021-02-14
13 Ahmed Bashandy Uploaded new revision
2021-02-13
12 (System) Document has expired
2021-01-29
12 Bruno Decraene Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Bruno Decraene. Sent review to list.
2021-01-17
12 Ines Robles Request for Last Call review by IOTDIR Completed: Ready with Nits. Reviewer: Ines Robles. Sent review to list.
2021-01-14
12 Min Ye Assignment of request for Last Call review by RTGDIR to Tony Przygienda was marked no-response
2021-01-14
12 Min Ye Request for Last Call review by RTGDIR is assigned to Bruno Decraene
2021-01-14
12 Min Ye Request for Last Call review by RTGDIR is assigned to Bruno Decraene
2021-01-10
12 Reese Enghardt Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Theresa Enghardt. Sent review to list.
2020-12-18
12 Brian Trammell Request for Last Call review by TSVART Completed: Ready. Reviewer: Brian Trammell. Sent review to list.
2020-12-17
12 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Tero Kivinen. Sent review to list.
2020-12-14
12 Wesley Eddy Request for Last Call review by TSVART is assigned to Brian Trammell
2020-12-14
12 Wesley Eddy Request for Last Call review by TSVART is assigned to Brian Trammell
2020-12-14
12 Ines Robles Request for Last Call review by IOTDIR is assigned to Ines Robles
2020-12-14
12 Ines Robles Request for Last Call review by IOTDIR is assigned to Ines Robles
2020-12-11
12 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Tony Przygienda
2020-12-11
12 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Tony Przygienda
2020-12-10
12 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tero Kivinen
2020-12-10
12 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tero Kivinen
2020-12-10
12 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Geoff Huston
2020-12-10
12 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Geoff Huston
2020-12-10
12 Jean Mahoney Request for Last Call review by GENART is assigned to Theresa Enghardt
2020-12-10
12 Jean Mahoney Request for Last Call review by GENART is assigned to Theresa Enghardt
2020-12-10
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2020-12-10
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2020-12-09
12 Jeff Tantsura IETF WG state changed to In WG Last Call from WG Document
2020-12-09
12 Jeff Tantsura Requested Last Call review by ARTART
2020-12-09
12 Jeff Tantsura Requested Last Call review by TSVART
2020-12-09
12 Jeff Tantsura Requested Last Call review by RTGDIR
2020-12-09
12 Jeff Tantsura Requested Last Call review by OPSDIR
2020-12-09
12 Jeff Tantsura Requested Last Call review by IOTDIR
2020-12-09
12 Jeff Tantsura Requested Last Call review by INTDIR
2020-12-09
12 Jeff Tantsura Requested Last Call review by GENART
2020-12-09
12 Jeff Tantsura Requested Last Call review by SECDIR
2020-12-09
12 Jeff Tantsura Notification list changed to Yingzhen Qu <yingzhen.ietf@gmail.com> from "Rob Shakir" <rjs@rob.sh>, Gaurav Dawra <gdawra@cisco.com>, Yingzhen Qu <yingzhen.ietf@gmail.com>
2020-11-20
Jenny Bui Posted related IPR disclosure Cisco Systems, Inc.'s Statement about IPR related to draft-ietf-rtgwg-bgp-pic
2020-11-16
Jenny Bui Posted related IPR disclosure Cisco Systems, Inc.'s Statement about IPR related to draft-ietf-rtgwg-bgp-pic
2020-08-12
12 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-12.txt
2020-08-12
12 (System) New version approved
2020-08-12
12 (System) Request for posting confirmation emailed to previous authors: Ahmed Bashandy , Clarence Filsfils , Prodosh Mohapatra
2020-08-12
12 Ahmed Bashandy Uploaded new revision
2020-07-26
11 Yingzhen Qu
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      An Informational Track RFC is being requested and is indicated in the
      title page header.

(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:

      This informational document is proposing a forwarding plane using
      multi-level forwarding chains with maximal sharing of forwarding
      objects. In case of failure, it can reroute a large number of
      destinations by modifying a small number of objects, and traffic
      can be re-routed to ECMP or pre-calculated backup paths in a timeframe
      that does not depend on the number of BGP prefixes.

Working Group Summary:

      During WG adoption call, it’s been agreed that this document is useful,
      and there are mature implementations.

Document Quality:

      This document has been a WG document for multiple years.
      It is stable, without changes to the technical solution and only
      clarifications.

Personnel:

      Yingzhen Qu is the Document Shepherd.
      Martin Vigoureux is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

    The document shepherd has reviewed the document and followed the discussion on the RTGWG mailing list.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(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.

(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? For example, perhaps he or she is
    uncomfortable with certain parts of the document, or has concerns
    whether there really is a need for it. In any event, if the WG has
    discussed those issues and has indicated that it still wishes to
    advance the document, detail those concerns here.

      None.

(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?

    There are still authors who didn’t reply to the IPR call.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.
   
    No.

(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?

    The document has not passed WGLC.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      The document has not passed WGLC.

(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.

      Nits are all resolved. Shepherd review comments have been addressed
      in version -11.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(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)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  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.

      No.

(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 5226).
 
Not applicable. No IANA registry needed.

(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.

      No 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, etc.

      Not applicable.
2020-03-12
11 Yingzhen Qu
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      An Informational Track RFC is being requested and is indicated in the
      title page header.

(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:

      This informational document is proposing a forwarding plane using
      multi-level forwarding chains with maximal sharing of forwarding
      objects. In case of failure, it can reroute a large number of
      destinations by modifying a small number of objects, and traffic
      can be re-routed to ECMP or pre-calculated backup paths in a timeframe
      that does not depend on the number of BGP prefixes.

Working Group Summary:

      During WG adoption call, it’s been agreed that this document is useful,
      and there are mature implementations.

Document Quality:

      This document has been a WG document for multiple years.
      It is stable, without changes to the technical solution and only
      clarifications.

Personnel:

      Yingzhen Qu is the Document Shepherd.
      Martin Vigoureux is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

    The document shepherd has reviewed the document and followed the discussion on the RTGWG mailing list.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(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.

(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? For example, perhaps he or she is
    uncomfortable with certain parts of the document, or has concerns
    whether there really is a need for it. In any event, if the WG has
    discussed those issues and has indicated that it still wishes to
    advance the document, detail those concerns here.

      None.

(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?

    There are still authors who didn’t reply to the IPR call.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.
   
    No.

(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?

      There is consensus from the WG that
      this document can progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      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.

      Nits are all resolved. Shepherd review comments have been addressed
      in version -11.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(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)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  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.

      No.

(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 5226).
 
Not applicable. No IANA registry needed.

(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.

      No 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, etc.

      Not applicable.
2020-02-10
11 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-11.txt
2020-02-10
11 (System) New version approved
2020-02-10
11 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Prodosh Mohapatra , Ahmed Bashandy
2020-02-10
11 Ahmed Bashandy Uploaded new revision
2019-12-20
10 Yingzhen Qu
Notification list changed to "Rob Shakir" <rjs@rob.sh>, Gaurav Dawra <gdawra@cisco.com>, Yingzhen Qu <yingzhen.ietf@gmail.com> from "Rob Shakir" <rjs@rob.sh>, …
Notification list changed to "Rob Shakir" <rjs@rob.sh>, Gaurav Dawra <gdawra@cisco.com>, Yingzhen Qu <yingzhen.ietf@gmail.com> from "Rob Shakir" <rjs@rob.sh>, Gaurav Dawra <gdawra@cisco.com>
2019-12-20
10 Yingzhen Qu Document shepherd changed to Yingzhen Qu
2019-10-02
10 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-10.txt
2019-10-02
10 (System) New version approved
2019-10-02
10 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Prodosh Mohapatra , Ahmed Bashandy
2019-10-02
10 Ahmed Bashandy Uploaded new revision
2019-04-01
09 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-09.txt
2019-04-01
09 (System) New version approved
2019-04-01
09 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Prodosh Mohapatra , Ahmed Bashandy
2019-04-01
09 Ahmed Bashandy Uploaded new revision
2019-04-01
08 (System) Document has expired
2018-09-28
08 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-08.txt
2018-09-28
08 (System) New version approved
2018-09-28
08 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Prodosh Mohapatra , Ahmed Bashandy
2018-09-28
08 Ahmed Bashandy Uploaded new revision
2018-04-02
07 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-07.txt
2018-04-02
07 (System) New version approved
2018-04-02
07 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Ahmed Bashandy , rtgwg-chairs@ietf.org, Prodosh Mohapatra
2018-04-02
07 Ahmed Bashandy Uploaded new revision
2017-11-20
06 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-06.txt
2017-11-20
06 (System) New version approved
2017-11-20
06 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Ahmed Bashandy , Prodosh Mohapatra
2017-11-20
06 Ahmed Bashandy Uploaded new revision
2017-11-11
05 Chris Bowers Tag Doc Shepherd Follow-up Underway cleared.
2017-11-11
05 Chris Bowers IETF WG state changed to WG Document from WG Consensus: Waiting for Write-Up
2017-11-07
05 Jeff Tantsura Notification list changed to "Rob Shakir" <rjs@rob.sh>, Gaurav Dawra <gdawra@cisco.com> from "Rob Shakir" <rjs@rob.sh>
2017-11-07
05 Jeff Tantsura Document shepherd changed to Gaurav Dawra
2017-05-25
05 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-05.txt
2017-05-25
05 (System) New version approved
2017-05-25
05 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Ahmed Bashandy , Prodosh Mohapatra
2017-05-25
05 Ahmed Bashandy Uploaded new revision
2017-05-22
04 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-04.txt
2017-05-22
04 (System) New version approved
2017-05-22
04 (System) Request for posting confirmation emailed to previous authors: Clarence Filsfils , Ahmed Bashandy , Prodosh Mohapatra
2017-05-22
04 Ahmed Bashandy Uploaded new revision
2016-11-22
03 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-03.txt
2016-11-22
03 (System) New version approved
2016-11-22
03 (System) Request for posting confirmation emailed to previous authors: "Clarence Filsfils" , "Ahmed Bashandy" , rtgwg-chairs@ietf.org, "Pradosh Mohapatra"
2016-11-22
03 Ahmed Bashandy Uploaded new revision
2016-08-01
02 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-02.txt
2016-07-18
01 Jeff Tantsura Tag Doc Shepherd Follow-up Underway set.
2016-07-18
01 Jeff Tantsura IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2016-06-21
01 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-01.txt
2016-06-10
00 Jeff Tantsura Notification list changed to "Rob Shakir" <rjs@rob.sh>
2016-06-10
00 Jeff Tantsura Document shepherd changed to Rob Shakir
2016-04-21
00 Jonathan Hardwick Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Bruno Decraene.
2016-04-11
00 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Bruno Decraene
2016-04-11
00 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Bruno Decraene
2015-12-08
00 Jeff Tantsura Intended Status changed to Informational from None
2015-12-08
00 Jeff Tantsura This document now replaces draft-bashandy-rtgwg-bgp-pic instead of None
2015-12-08
00 Ahmed Bashandy New version available: draft-ietf-rtgwg-bgp-pic-00.txt