Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX)
draft-ietf-opsawg-ipfix-mpls-sr-label-type-11

[Ballot comment]
Nice work on the shepherd writeup.

This was the only working group document on this week's IESG telechat, which is remarkable.  It can truly be said that it got thorough IESG review.

[Ballot comment]
This document presents a couple use cases for the new IE 46 codepoints,
but both are in the context of monitoring the rollout of a migration of
control-plane technology.  Are there steady-state use cases for these
values?

Section 2

  Another use case is to monitor MPLS control plane migrations from
  dynamic BGP labels [RFC8277] to BGP Prefix-SIDs in the context of
  Seamless MPLS SR described in Section 4.6 of
  [I-D.hegde-spring-mpls-seamless-sr].

I'm not sure that draft-hegde-spring-mpls-seamless-sr is at a state of
maturity to be a good reference here (and thus, that this example is
worth including).  For example, the referenced section refers to "option
A", "option B", and "option C" but I couldn't find where in the document
these options were enumerated as such.  (Maybe it's supposed to be
what's described in sections 4.1.{1,2,3}; maybe not.) (Further aside
about that draft: it also isn't using the RFC 8174 version of the BCP 14
boilerplate, and has more authors than recommended by the RFC Series
Editor statement on authorship,
https://www.rfc-editor.org/pipermail/rfc-interest/2015-May/008869.html
.)

Section 5

If pressed to come up with new security considerations from this work, I
would submit that conveying information about what control-plane
protocol is in use gives an attacker information to use in planning an
attack on that control plane.  But the attacker would need to have
access to the IPFIX information in order to do so, and RFCs 7012 and
7011 are clear that the mechanism for conveying the IPFIX data has to
provide confidentiality protection, so it seems that endpoint compromise
would be needed for the attacker to actually gain access, and it's hard
to come up with a realistic scenario involving endpoint compromise where
these new codepoints are key to an attack.  In short, it doesn't really
seem like a consideration that's relevant enough to be worth mentioning
in this document, so I'm okay with leaving this section as-is.

The most that I would suggest changing is to add the word "significant",
for "no significant extra security considerations".

NITS

Section 1

  Four new routing protocol extensions, OSPFv2 Extensions [RFC8665],

I suggest dropping the word "new", which is a relative term and will be
less and less applicable over time.

  Also, [I-D.ali-spring-sr-traffic-accounting] describes how IP Flow
  Information Export [RFC7012] can be leveraged to account traffic to
  MPLS SR label dimensions within a Segment Routing domain.

I don't understand the word "dimensions" in this context.  (It doesn't
appear in the referenced documents, either, which suggests that a
different word may have been intended.)

[Ballot comment]
Thank you for the work put into this document.

I have only one suggestion: expand "IE" on the first use.

Special thanks to Med Boucadair for his detailed shepherd's write-up notably about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

[Ballot comment]
(1) The SR labels can also be programmed by a PCE (rfc8664).  For completeness, it would be very nice if a codepoint was also allocated for that.

(2) The "Additional Information" field in the IPFIX Information Elements registry includes information about mplsTopLabelType that will now be incomplete -- it currently says:

  See [RFC3031] for the MPLS label structure. See [RFC4364] for the
  association of MPLS labels with Virtual Private Networks (VPNs).
  See [RFC4271] for BGP and BGP routing. See [RFC5036] for Label
  Distribution Protocol (LDP). See the list of MPLS label types
  assigned by IANA at [http://www.iana.org/assignments/mpls-label-values].

It would be nice to add information here about the new fields.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-opsawg-ipfix-mpls-sr-label-type-06. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the IPFIX Information Elements registry on the IP Flow Information Export (IPFIX) Entities registry page located at:

https://www.iana.org/assignments/ipfix/

For IPFIX MPLS label type (Value 46), four new registrations are to be made as follows:

Value: [ TBD-at-Registration ]
Description: OSPFv2 Segment Routing
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: OSPFv3 Segment Routing
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: IS-IS Segment Routing
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: BGP Segment Routing Prefix-SID
Reference: [ RFC-to-be ]

In section 3 of the current draft, the author provides "Additional Information" as part of the registrations. However, there is no such field in this subregistry. As a result, IANA requests that the author modify Section 3 to reflect this. "References" and "Requester" in the IPFIX Information Elements registry were just changed to "Additional Information" and "Reference". However, this change does not affect the IPFIX MPLS label type (Value 46) registry.

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

Shepherd write-up for draft-ietf-opsawg-ipfix-mpls-sr-label-type-05

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

    This document requests publication as an Informational RFC. That is
    indicated on the header page.

    The intended status is justified given that the document includes
    informative use cases to illustrate the use of the new types
    and it does not include any normative statements. Moreover, the
    registration policy for the target IANA registry (MPLS label types)
    is "Expert Review".

    Note that publishing this document as an RFC makes sense as RFC 7012
    says the following:

        || "The specification of new MPLS label types MUST be published using a
        ||  well-established and persistent publication medium."

(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 document defines new IP Flow Information Export (IPFIX) types to
      identify which traffic is being forwarded based upon which MPLS control
      plane protocol within a Segment Routing (SR) domain.  To that aim,
      the document registers four new types for the IPFIX mplsTopLabelType
      Information Element (#46): IS-IS, OSPFv2, OSPFv3, and BGP MPLS
      SR extensions. These new types can be used, for example, to
      monitor MPLS control plane migrations from LDP to IS-IS (or OSPF)
      Segment Routing. Other use cases are discussed in the document.

    Working Group Summary:

      This document ran 7 versions before adoption by opsawg.

      No major points of contention were encountered during the call for
      adoption based on -07, development, and WGLC.

      Note that a first attempt to adopt the work was made right after the
      adoption hum that occurred during the IETF#108 virtual meeting. That
      call was not conclusive as there was few support at the time.

      Prior to the adoption by opsawg, Thomas requested feedback from
      various WGs:

      o  mpls wg: The main comment was related to the reference that is
          indicated in the IANA section (whether this should be this
          document or the document that defines the actual mechanism).

      o  lsr wg: The main comment was a suggestion to add a value for BGP
          Prefix-SID, which the author appropriately addressed.

      o  spring wg: The main input was to consider separate values for
          OSPFv2 and OSPFv3. No objection to proceed with publication in
          opsawg.

      Thomas implemented the required changes to take into account the
      feedback received from these WGs, including comments from opsawg.

      An early version of the document was reviewed by IE doctors, Paul
      Aitken and Andrew Feren. 

      Amanda (IANA) clarified that in the Information Elements registry,
      the name "Requester" in the "parent" registry was being used where
      IANA traditionally uses the label "Reference". In fact,  the subregistries
      have always used the word "Reference". After receiving the  author's
      request to add "Requester" to the subregistry to bring it in line with
      the parent registry, the decision was instead made to change "Requester"
      to "Reference" in the Information Elements registry and to rename that
      registry's "References" column "Additional Information". The confusion
      was introduced by IANA when instead of telling the author to remove the
      "Requester" column from the subregistry request, IANA told him
      to use "Additional Information" and "Reference", as if the request was
      about a request registration in the IE registry.

      The issue about the IANA request information was brought up during
      the IETF Last-Call. IANA clarified the issue root and that the extra
      column will be removed from the registration request. 

      This document focuses on MPLS-SR; SRv6-specific IEs are defined in
      https://tools.ietf.org/html/draft-patki-srv6-ipfix.

    Document Quality:

      The document benefited from reviews from many WGs.
      These reviews helped to enhance the quality of the document.

    Personnel:

      The document shepherd is Mohamed Boucadair
      The Responsible Area Director is Robert Wilton

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd.

    At least, two detailed reviews were made by the Document Shepherd:

      * WGLC: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-01-rev%20Med.pdf
      * Shepherd Review: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-02-rev%20Med.pdf

    Also, the Document Shepherd shared comments for -07 as part of the WG
    Call for Adoption.

    The author has taken into account these various reviews.

    This version is ready for publication.

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

    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?

    I used to have an issue with the Intended Status (Standards Track) of
    the document given that it does not include any normative statement
    and the IANA registration policy does not require a Standards Track RFC.
    After discussion with the WG and the author, it was decided to change
    the intended status to Informational as part of the Shepherd review.

    I have no concern with -05.

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

    Yes.

    The IPR response from the author can be seen at:
      https://mailarchive.ietf.org/arch/msg/opsawg/7m3sRo18BTmGwSC6RVBMoVB9LCg/

(8) Has an IPR disclosure been filed that references this document?

    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 consensus is solid.

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

    idnits is clean.

(12) Describe how the document meets any required formal review
    criteria

    No formal language is used.

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

    All normative references are published RFCs.

(15) Are there downward normative references references (see
    RFC 3967)?

    No downrefs.

(16) Will publication of this document change the status of any
    existing RFCs?

    No.

(17) Describe the Document Shepherd's review of the IANA
    considerations section.

    The document requests IANA to register four values in the "IPFIX MPLS
    label type (Value 46)" subregistry. The registry is well identified
    (a pointer is provided). The required information to proceed with
    the registrations is provided. 
   
    A forth column was added by the author as he was mistakenly informed 
    by IANA that such column is hidden from the IE46 registry. The extra
    column need to be removed. 

(18) List any new IANA registries that require Expert Review for
    future allocations.

    None.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language.

    N/A

(20) If the document contains a YANG module

    N/A

Shepherd write-up for draft-ietf-opsawg-ipfix-mpls-sr-label-type-05

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

    This document requests publication as an Informational RFC. That is
    indicated on the header page.

    The intended status is justified given that the document includes
    informative use cases to illustrate the use of the new types
    and it does not include any normative statements. Moreover, the
    registration policy for the target IANA registry (MPLS label types)
    is "Expert Review".

    Note that publishing this document as an RFC makes sense as RFC 7012
    says the following:

        || "The specification of new MPLS label types MUST be published using a
        ||  well-established and persistent publication medium."

(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 document defines new IP Flow Information Export (IPFIX) types to
      identify which traffic is being forwarded based upon which MPLS control
      plane protocol within a Segment Routing (SR) domain.  To that aim,
      the document registers four new types for the IPFIX mplsTopLabelType
      Information Element (#46): IS-IS, OSPFv2, OSPFv3, and BGP MPLS
      SR extensions. These new types can be used, for example, to
      monitor MPLS control plane migrations from LDP to IS-IS (or OSPF)
      Segment Routing. Other use cases are discussed in the document.

    Working Group Summary:

      This document ran 7 versions before adoption by opsawg.

      No major points of contention were encountered during the call for
      adoption based on -07, development, and WGLC.

      Note that a first attempt to adopt the work was made right after the
      adoption hum that occurred during the IETF#108 virtual meeting. That
      call was not conclusive as there was few support at the time.

      Prior to the adoption by opsawg, Thomas requested feedback from
      various WGs:

      o  mpls wg: The main comment was related to the reference that is
          indicated in the IANA section (whether this should be this
          document or the document that defines the actual mechanism).

      o  lsr wg: The main comment was a suggestion to add a value for BGP
          Prefix-SID, which the author appropriately addressed.

      o  spring wg: The main input was to consider separate values for
          OSPFv2 and OSPFv3. No objection to proceed with publication in
          opsawg.

      Thomas implemented the required changes to take into account the
      feedback received from these WGs, including comments from opsawg.

      An early version of the document was reviewed by IE doctors, Paul
      Aitken and Andrew Feren.  The review revealed that "Requester" column
      is hidden in the IANA page; the content in "References" column should
      be in "Requester" column and vice versa. The IPFIX registry was updated
      with the following note added to that registry:

          The columns previously titled "References" and "Requester" have been
          renamed "Additional Information" and "Reference", respectively.
   
      It happened during the review that IANA mistook the requested
      subregistry entries for Information Elements entries and informed the
      author to use those IE-specific fields.

      This document focuses on MPLS-SR; SRv6-specific IEs are defined in
      https://tools.ietf.org/html/draft-patki-srv6-ipfix.

    Document Quality:

      The document benefited from reviews from many WGs.
      These reviews helped to enhance the quality of the document.

    Personnel:

      The document shepherd is Mohamed Boucadair
      The Responsible Area Director is Robert Wilton

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd.

    At least, two detailed reviews were made by the Document Shepherd:

      * WGLC: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-01-rev%20Med.pdf
      * Shepherd Review: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-02-rev%20Med.pdf

    Also, the Document Shepherd shared comments for -07 as part of the WG
    Call for Adoption.

    The author has taken into account these various reviews.

    This version is ready for publication.

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

    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?

    I used to have an issue with the Intended Status (Standards Track) of
    the document given that it does not include any normative statement
    and the IANA registration policy does not require a Standards Track RFC.
    After discussion with the WG and the author, it was decided to change
    the intended status to Informational as part of the Shepherd review.

    I have no concern with -05.

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

    Yes.

    The IPR response from the author can be seen at:
      https://mailarchive.ietf.org/arch/msg/opsawg/7m3sRo18BTmGwSC6RVBMoVB9LCg/

(8) Has an IPR disclosure been filed that references this document?

    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 consensus is solid.

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

    idnits is clean.

(12) Describe how the document meets any required formal review
    criteria

    No formal language is used.

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

    All normative references are published RFCs.

(15) Are there downward normative references references (see
    RFC 3967)?

    No downrefs.

(16) Will publication of this document change the status of any
    existing RFCs?

    No.

(17) Describe the Document Shepherd's review of the IANA
    considerations section.

    The document requests IANA to register four values in the "IPFIX MPLS
    label type (Value 46)" subregistry. The registry is well identified
    (a pointer is provided). The required information to proceed with
    the registrations is provided. 
   
    A forth column was added by the author as he was mistakenly informed 
    by IANA that such column is hidden from the IE46 registry. The extra
    column need to be removed. 

(18) List any new IANA registries that require Expert Review for
    future allocations.

    None.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language.

    N/A

(20) If the document contains a YANG module

    N/A

Shepherd write-up for draft-ietf-opsawg-ipfix-mpls-sr-label-type-05

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

    This document requests publication as an Informational RFC. That is
    indicated on the header page.

    The intended status is justified given that the document includes
    informative use cases to illustrate the use of the new types
    and it does not include any normative statements. Moreover, the
    registration policy for the target IANA registry (MPLS label types)
    is "Expert Review".

    Note that publishing this document as an RFC makes sense as RFC 7012
    says the following:

        || "The specification of new MPLS label types MUST be published using a
        ||  well-established and persistent publication medium."

(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 document defines new IP Flow Information Export (IPFIX) types to
      identify which traffic is being forwarded based upon which MPLS control
      plane protocol within a Segment Routing (SR) domain.  To that aim,
      the document registers four new types for the IPFIX mplsTopLabelType
      Information Element (#46): IS-IS, OSPFv2, OSPFv3, and BGP MPLS
      SR extensions. These new types can be used, for example, to
      monitor MPLS control plane migrations from LDP to IS-IS (or OSPF)
      Segment Routing. Other use cases are discussed in the document.

    Working Group Summary:

      This document ran 7 versions before adoption by opsawg.

      No major points of contention were encountered during the call for
      adoption based on -07, development, and WGLC.

      Note that a first attempt to adopt the work was made right after the
      adoption hum that occurred during the IETF#108 virtual meeting. That
      call was not conclusive as there was few support at the time.

      Prior to the adoption by opsawg, Thomas requested feedback from
      various WGs:

      o  mpls wg: The main comment was related to the reference that is
          indicated in the IANA section (whether this should be this
          document or the document that defines the actual mechanism). This
          is fixed as the IANA registry has two columns (one of them is
          hidden and has to be fixed, see below): "Requester" column and
          "References" column.

      o  lsr wg: The main comment was a suggestion to add a value for BGP
          Prefix-SID, which the author appropriately addressed.

      o  spring wg: The main input was to consider separate values for
          OSPFv2 and OSPFv3. No objection to proceed with publication in
          opsawg.

      Thomas implemented the required changes to take into account the
      feedback received from these WGs, including comments from opsawg.

      An early version of the document was reviewed by IE doctors, Paul
      Aitken and Andrew Feren. The review revealed that "Requester" column
      is hidden in the IANA page; the content in "References" column should
      be in "Requester" column and vice versa. As an outcome, the "References"
      column should be renamed to "Additional Information".  Both IANA and IE
      doctors confirmed that IE46 registry will be fixed when making the actions
      that are requested by this I-D. The table in the "IANA Considerations"
      Section of this document will be updated (by the author or RFC Editor) once
      the IANA registry is renamed from "References" to "Additional Information".
     
      (01/07) The IANA added this note to https://www.iana.org/assignments/ipfix/ipfix.xhtml:
        || The columns previously titled "References" and "Requester" have been renamed
        || "Additional Information" and "Reference", respectively."

      This document focuses on MPLS-SR; SRv6-specific IEs are defined in
      https://tools.ietf.org/html/draft-patki-srv6-ipfix.

    Document Quality:

      The document benefited from reviews from many WGs.
      These reviews helped to enhance the quality of the document.

    Personnel:

      The document shepherd is Mohamed Boucadair
      The Responsible Area Director is Robert Wilton

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd.

    At least, two detailed reviews were made by the Document Shepherd:

      * WGLC: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-01-rev%20Med.pdf
      * Shepherd Review: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-02-rev%20Med.pdf

    Also, the Document Shepherd shared comments for -07 as part of the WG
    Call for Adoption.

    The author has taken into account these various reviews.

    This version is ready for publication.

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

    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?

    I used to have an issue with the Intended Status (Standards Track) of
    the document given that it does not include any normative statement
    and the IANA registration policy does not require a Standards Track RFC.
    After discussion with the WG and the author, it was decided to change
    the intended status to Informational as part of the Shepherd review.

    I have no concern with -05.

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

    Yes.

    The IPR response from the author can be seen at:
      https://mailarchive.ietf.org/arch/msg/opsawg/7m3sRo18BTmGwSC6RVBMoVB9LCg/

(8) Has an IPR disclosure been filed that references this document?

    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 consensus is solid.

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

    idnits is clean.

(12) Describe how the document meets any required formal review
    criteria

    No formal language is used.

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

    All normative references are published RFCs.

(15) Are there downward normative references references (see
    RFC 3967)?

    No downrefs.

(16) Will publication of this document change the status of any
    existing RFCs?

    No.

(17) Describe the Document Shepherd's review of the IANA
    considerations section.

    The document requests IANA to register four values in the "IPFIX MPLS
    label type (Value 46)" subregistry. The registry is well identified
    (a pointer is provided). The required information to proceed with
    the registrations is provided, including the hidden column (refer to
    the Working Group Summary).

    These actions are appropriately captured in the document.

    As indicated in the Working Group Summary, the table in the IANA
    Considerations section will be updated (by the author or RFC Editor)
    once the IANA registry is renamed from "References" to "Additional
    Information".

(18) List any new IANA registries that require Expert Review for
    future allocations.

    None.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language.

    N/A

(20) If the document contains a YANG module

    N/A

The following Last Call announcement was sent out (ends 2021-07-20):

From: The IESG
To: IETF-Announce
CC: draft-ietf-opsawg-ipfix-mpls-sr-label-type@ietf.org, mohamed.boucadair@orange.com, opsawg-chairs@ietf.org, opsawg@ietf.org, rwilton@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX)) to Informational RFC


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'Export of
MPLS Segment Routing Label Type Information in IP Flow
  Information Export (IPFIX)'
  as Informational 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-call@ietf.org mailing lists by 2021-07-20. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document introduces new IP Flow Information Export (IPFIX) code
  points to identify which traffic is being forwarded based on which
  MPLS control plane protocol used within a Segment Routing domain.  In
  particular, this document defines four code points for the IPFIX
  mplsTopLabelType Information Element for IS-IS, OSPFv2, OSPFv3, and
  BGP MPLS Segment Routing extensions.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-mpls-sr-label-type/



No IPR declarations have been submitted directly on this I-D.

Shepherd write-up for draft-ietf-opsawg-ipfix-mpls-sr-label-type-05

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

    This document requests publication as an Informational RFC. That is
    indicated on the header page.

    The intended status is justified given that the document includes
    informative use cases to illustrate the use of the new types
    and it does not include any normative statements. Moreover, the
    registration policy for the target IANA registry (MPLS label types)
    is "Expert Review".

    Note that publishing this document as an RFC makes sense as RFC 7012
    says the following:

        || "The specification of new MPLS label types MUST be published using a
        ||  well-established and persistent publication medium."

(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 document defines new IP Flow Information Export (IPFIX) types to
      identify which traffic is being forwarded based upon which MPLS control
      plane protocol within a Segment Routing (SR) domain.  To that aim,
      the document registers four new types for the IPFIX mplsTopLabelType
      Information Element (#46): IS-IS, OSPFv2, OSPFv3, and BGP MPLS
      SR extensions. These new types can be used, for example, to
      monitor MPLS control plane migrations from LDP to IS-IS (or OSPF)
      Segment Routing. Other use cases are discussed in the document.

    Working Group Summary:

      This document ran 7 versions before adoption by opsawg.

      No major points of contention were encountered during the call for
      adoption based on -07, development, and WGLC.

      Note that a first attempt to adopt the work was made right after the
      adoption hum that occurred during the IETF#108 virtual meeting. That
      call was not conclusive as there was few support at the time.

      Prior to the adoption by opsawg, Thomas requested feedback from
      various WGs:

      o  mpls wg: The main comment was related to the reference that is
          indicated in the IANA section (whether this should be this
          document or the document that defines the actual mechanism). This
          is fixed as the IANA registry has two columns (one of them is
          hidden and has to be fixed, see below): "Requester" column and
          "References" column.

      o  lsr wg: The main comment was a suggestion to add a value for BGP
          Prefix-SID, which the author appropriately addressed.

      o  spring wg: The main input was to consider separate values for
          OSPFv2 and OSPFv3. No objection to proceed with publication in
          opsawg.

      Thomas implemented the required changes to take into account the
      feedback received from these WGs, including comments from opsawg.

      An early version of the document was reviewed by IE doctors, Paul
      Aitken and Andrew Feren. The review revealed that "Requester" column
      is hidden in the IANA page; the content in "References" column should
      be in "Requester" column and vice versa. As an outcome, the "References"
      column should be renamed to "Additional Information".  Both IANA and IE
      doctors confirmed that IE46 registry will be fixed when making the actions
      that are requested by this I-D. The table in the "IANA Considerations"
      Section of this document will be updated (by the author or RFC Editor) once
      the IANA registry is renamed from "References" to "Additional Information".

      This document focuses on MPLS-SR; SRv6-specific IEs are defined in
      https://tools.ietf.org/html/draft-patki-srv6-ipfix.

    Document Quality:

      The document benefited from reviews from many WGs.
      These reviews helped to enhance the quality of the document.

    Personnel:

      The document shepherd is Mohamed Boucadair
      The Responsible Area Director is Robert Wilton

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd.

    At least, two detailed reviews were made by the Document Shepherd:

      * WGLC: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-01-rev%20Med.pdf
      * Shepherd Review: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-02-rev%20Med.pdf

    Also, the Document Shepherd shared comments for -07 as part of the WG
    Call for Adoption.

    The author has taken into account these various reviews.

    This version is ready for publication.

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

    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?

    I used to have an issue with the Intended Status (Standards Track) of
    the document given that it does not include any normative statement
    and the IANA registration policy does not require a Standards Track RFC.
    After discussion with the WG and the author, it was decided to change
    the intended status to Informational as part of the Shepherd review.

    I have no concern with -05.

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

    Yes.

    The IPR response from the author can be seen at:
      https://mailarchive.ietf.org/arch/msg/opsawg/7m3sRo18BTmGwSC6RVBMoVB9LCg/

(8) Has an IPR disclosure been filed that references this document?

    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 consensus is solid.

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

    idnits is clean.

(12) Describe how the document meets any required formal review
    criteria

    No formal language is used.

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

    All normative references are published RFCs.

(15) Are there downward normative references references (see
    RFC 3967)?

    No downrefs.

(16) Will publication of this document change the status of any
    existing RFCs?

    No.

(17) Describe the Document Shepherd's review of the IANA
    considerations section.

    The document requests IANA to register four values in the "IPFIX MPLS
    label type (Value 46)" subregistry. The registry is well identified
    (a pointer is provided). The required information to proceed with
    the registrations is provided, including the hidden column (refer to
    the Working Group Summary).

    These actions are appropriately captured in the document.

    As indicated in the Working Group Summary, the table in the IANA
    Considerations section will be updated (by the author or RFC Editor)
    once the IANA registry is renamed from "References" to "Additional
    Information".

(18) List any new IANA registries that require Expert Review for
    future allocations.

    None.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language.

    N/A

(20) If the document contains a YANG module

    N/A

Shepherd write-up for draft-ietf-opsawg-ipfix-mpls-sr-label-type-05

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

    This document requests publication as an Informational RFC. That is
    indicated on the header page.

    The intended status is justified given that the document includes
    informative use cases to illustrate the use of the new types
    and it does not include any normative statements. Moreover, the
    registration policy for the target IANA registry (MPLS label types)
    is "Expert Review".

    Note that publishing this document as an RFC makes sense as RFC 7012
    says the following:

        || "The specification of new MPLS label types MUST be published using a
        ||  well-established and persistent publication medium."

(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 document defines new IP Flow Information Export (IPFIX) types to
      identify which traffic is being forwarded based upon which MPLS control
      plane protocol within a Segment Routing (SR) domain.  To that aim,
      the document registers four new types for the IPFIX mplsTopLabelType
      Information Element (#46): IS-IS, OSPFv2, OSPFv3, and BGP MPLS
      SR extensions. These new types can be used, for example, to
      monitor MPLS control plane migrations from LDP to IS-IS (or OSPF)
      Segment Routing. Other use cases are discussed in the document.

    Working Group Summary:

      This document ran 7 versions before adoption by opsawg.

      No major points of contention were encountered during the call for
      adoption based on -07, development, and WGLC.

      Note that a first attempt to adopt the work was made right after the
      adoption hum that occurred during the IETF#108 virtual meeting. That
      call was not conclusive as there was few support at the time.

      Prior to the adoption by opsawg, Thomas requested feedback from
      various WGs:

      o  mpls wg: The main comment was related to the reference that is
          indicated in the IANA section (whether this should be this
          document or the document that defines the actual mechanism). This
          is fixed as the IANA registry has two columns (one of them is
          hidden and has to be fixed, see below): "Requester" column and
          "References" column.

      o  lsr wg: The main comment was a suggestion to add a value for BGP
          Prefix-SID, which the author appropriately addressed.

      o  spring wg: The main input was to consider separate values for
          OSPFv2 and OSPFv3. No objection to proceed with publication in
          opsawg.

      Thomas implemented the required changes to take into account the
      feedback received from these WGs, including comments from opsawg.

      An early version of the document was reviewed by IE doctors, Paul
      Aitken and Andrew Feren. The review revealed that "Requester" column
      is hidden in the IANA page; the content in "References" column should
      be in "Requester" column and vice versa. As an outcome, the "References"
      column should be renamed to "Additional Information".  Both IANA and IE
      doctors confirmed that IE46 registry will be fixed when making the actions
      that are requested by this I-D. The table in the "IANA Considerations"
      Section of this document will be updated (by the author or RFC Editor) once
      the IANA registry is renamed from "References" to "Additional Information".

      This document focuses on MPLS-SR; SRv6-specific IEs are defined in
      https://tools.ietf.org/html/draft-patki-srv6-ipfix.

    Document Quality:

      The document benefited from reviews from many WGs.
      These reviews helped to enhance the quality of the document.

    Personnel:

      The document shepherd is Mohamed Boucadair
      The Responsible Area Director is Robert Wilton

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd.

    At least, two detailed reviews were made by the Document Shepherd:

      * WGLC: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-01-rev%20Med.pdf
      * Shepherd Review: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-02-rev%20Med.pdf

    Also, the Document Shepherd shared comments for -07 as part of the WG
    Call for Adoption.

    The author has taken into account these various reviews.

    This version is ready for publication.

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

    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?

    I used to have an issue with the Intended Status (Standards Track) of
    the document given that it does not include any normative statement
    and the IANA registration policy does not require a Standards Track RFC.
    After discussion with the WG and the author, it was decided to change
    the intended status to Informational as part of the Shepherd review.

    I have no concern with -05.

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

    Yes.

    The IPR response from the author can be seen at:
      https://mailarchive.ietf.org/arch/msg/opsawg/7m3sRo18BTmGwSC6RVBMoVB9LCg/

(8) Has an IPR disclosure been filed that references this document?

    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 consensus is solid.

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

    idnits is clean.

(12) Describe how the document meets any required formal review
    criteria

    No formal language is used.

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

    All normative references are published RFCs.

(15) Are there downward normative references references (see
    RFC 3967)?

    No downrefs.

(16) Will publication of this document change the status of any
    existing RFCs?

    No.

(17) Describe the Document Shepherd's review of the IANA
    considerations section.

    The document requests IANA to register four values in the "IPFIX MPLS
    label type (Value 46)" subregistry. The registry is well identified
    (a pointer is provided). The required information to proceed with
    the registrations is provided, including the hidden column (refer to
    the Working Group Summary).

    These actions are appropriately captured in the document.

    As indicated in the Working Group Summary, the table in the IANA
    Considerations section will be updated (by the author or RFC Editor)
    once the IANA registry is renamed from "References" to "Additional
    Information".

(18) List any new IANA registries that require Expert Review for
    future allocations.

    None.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language.

    N/A

(20) If the document contains a YANG module

    N/A

Shepherd write-up for draft-ietf-opsawg-ipfix-mpls-sr-label-type-05

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

    This document requests publication as an Informational RFC. That is
    indicated on the header page.

    The intended status is justified given that the document includes
    informative use cases to illustrate the use of the new types
    and it does not include any normative statements. Moreover, the
    registration policy for the target IANA registry (MPLS label types)
    is "Expert Review".

    Note that publishing this document as an RFC makes sense as RFC 7012
    says the following:

        || "The specification of new MPLS label types MUST be published using a
        ||  well-established and persistent publication medium."

(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 document defines new IP Flow Information Export (IPFIX) types to
      identify which traffic is being forwarded based upon which MPLS control
      plane protocol within a Segment Routing (SR) domain.  To that aim,
      the document registers four new types for the IPFIX mplsTopLabelType
      Information Element (#46): IS-IS, OSPFv2, OSPFv3, and BGP MPLS
      SR extensions. These new types can be used, for example, to
      monitor MPLS control plane migrations from LDP to IS-IS (or OSPF)
      Segment Routing. Other use cases are discussed in the document.

    Working Group Summary:

      This document ran 7 versions before adoption by opsawg.

      No major points of contention were encountered during the call for
      adoption based on -07, development, and WGLC.

      Note that a first attempt to adopt the work was made right after the
      adoption hum that occurred during the IETF#108 virtual meeting. That
      call was not conclusive as there was few support at the time.

      Prior to the adoption by opsawg, Thomas requested feedback from
      various WGs:

      o  mpls wg: The main comment was related to the reference that is
          indicated in the IANA section (whether this should be this
          document or the document that defines the actual mechanism). This
          is fixed as the IANA registry has two columns (one of them is
          hidden and has to be fixed, see below): "Requester" column and
          "References" column.

      o  lsr wg: The main comment was a suggestion to add a value for BGP
          Prefix-SID, which the author appropriately addressed.

      o  spring wg: The main input was to consider separate values for
          OSPFv2 and OSPFv3. No objection to proceed with publication in
          opsawg.

      Thomas implemented the required changes to take into account the
      feedback received from these WGs, including comments from opsawg.

      An early version of the document was reviewed by IE doctors, Paul
      Aitken and Andrew Feren. The review revealed that "Requester" column
      is hidden in the IANA page; the content in "References" column should
      be in "Requester" column and vice versa. As an outcome, the "References"
      column should be renamed to "Additional Information".  Both IANA and IE
      doctors confirmed that IE46 registry will be fixed when making the actions
      that are requested by this I-D. The table in the "IANA Considerations"
      Section of this document will be updated (by the author or RFC Editor) once
      the IANA registry is renamed from "References" to "Additional Information".

      This document focuses on MPLS-SR; SRv6-specific IEs are defined in
      https://tools.ietf.org/html/draft-patki-srv6-ipfix.

    Document Quality:

      The document benefited from reviews from many WGs.
      These reviews helped to enhance the quality of the document.

    Personnel:

      The document shepherd is Mohamed Boucadair
      The Responsible Area Director is Robert Wilton

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd.

    At least, two detailed reviews were made by the Document Shepherd:

      * WGLC: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-01-rev%20Med.pdf
      * Shepherd Review: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-drip-reqs-06-rev%20Med.pdf

    Also, the Document Shepherd shared comments for -07 as part of the WG
    Call for Adoption.

    The author has taken into account these various reviews.

    This version is ready for publication.

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

    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?

    I used to have an issue with the Intended Status (Standards Track) of
    the document given that it does not include any normative statement
    and the IANA registration policy does not require a Standards Track RFC.
    After discussion with the WG and the author, it was decided to change
    the intended status to Informational as part of the Shepherd review.

    I have no concern with -05.

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

    Yes.

    The IPR response from the author can be seen at:
      https://mailarchive.ietf.org/arch/msg/opsawg/7m3sRo18BTmGwSC6RVBMoVB9LCg/

(8) Has an IPR disclosure been filed that references this document?

    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 consensus is solid.

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

    idnits is clean.

(12) Describe how the document meets any required formal review
    criteria

    No formal language is used.

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

    All normative references are published RFCs.

(15) Are there downward normative references references (see
    RFC 3967)?

    No downrefs.

(16) Will publication of this document change the status of any
    existing RFCs?

    No.

(17) Describe the Document Shepherd's review of the IANA
    considerations section.

    The document requests IANA to register four values in the "IPFIX MPLS
    label type (Value 46)" subregistry. The registry is well identified
    (a pointer is provided). The required information to proceed with
    the registrations is provided, including the hidden column (refer to
    the Working Group Summary).

    These actions are appropriately captured in the document.

    As indicated in the Working Group Summary, the table in the IANA
    Considerations section will be updated (by the author or RFC Editor)
    once the IANA registry is renamed from "References" to "Additional
    Information".

(18) List any new IANA registries that require Expert Review for
    future allocations.

    None.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language.

    N/A

(20) If the document contains a YANG module

    N/A