Applicability of Border Gateway Protocol - Link State (BGP-LS) with Multi-Topology (MT) for Segment Routing based Network Resource Partitions (NRPs)
draft-ietf-idr-bgpls-sr-vtn-mt-14

[Ballot comment]
Hi Chongfeng, Cong, Jie, and Zhenbin,

Thank you for the constructive discussion. The changes made in 13/14 [1] addresses the points raised in my previous ballot [2]. Taking into account IDR WG scope, the changes rightfully call specific items (key for concrete realization) as out of scope. Also, the updated text is much aligned with the provisions in RFC9543 for NRP variants with regards to mapping to underlying topologies. The applicability to 1:1 is also better clarified.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-idr-bgpls-sr-vtn-mt-12&url2=draft-ietf-idr-bgpls-sr-vtn-mt-14&difftype=--hwdiff

[2] https://mailarchive.ietf.org/arch/msg/idr/UezG4TukKG66f0xDuzH-p70EiT0/

[Ballot comment]
I read this and found it interesting, but did not see transport-related issues that need to be addressed.

There is a spurious space after this "section 5.2.2.1 of [RFC9552] ."

[Ballot discuss]
Thank you for this document. I would like to DISCUSS whether this document is consistent with RFC 9543 and/or whether certain aspects of RFC 9543 are out of scope. This document seems to require that there is a 1:1 relationship between NRP and Topology-ID whereas RFC 9543 says the following:

Some NRP realizations may
  build NRPs with dedicated topologies, while other realizations may
  use a shared topology for multiple NRPs.

This document appears to support the first part of the above aka. "Some NRP realizations may build NRPs with dedicated topologies" but is mute on the second part "while other realizations may use a shared topology for multiple NPRs". Would the authors please clarify this and if multiple NRP to shared topology mapping is not supported then make this clearer in the document with justification as to why both cannot be supported.

[Ballot discuss]
Hi Chongfeng, Cong, Jie, and Zhenbin,

Thank you for the effort put into this specification.

Also, thanks to Nagendra Nainar for the OPSDIR review and to the authors for the follow-up.

I’m supportive of work that helps/informs deployments and walk through the applicability of some technologies. However, I’m having some issues that I’d like to DISCUSS.

# Why this needs to be published as an RFC? This is especially exacerbated by the 1:1 (NRP:MT-ID) mapping assumption:

Section 4:
  The mechanism described in this document assumes that each NRP is
  associated with an independent topology, and for the inter-domain
  NRPs, the MT-IDs used in the involved domains are consistent, so that
  the associated MT-ID can be used to identify the NRP in the control
  plane.

Isn’t then obvious to operate existing tools with such MT ID as input? What operational aspects triggered by the specific NRP case are worth additional considerations to be recorded in an RFC?

## What NRP specifics are being discussed in the document? Wouldn’t the same considerations in the draft apply based on MT IDs independent of which “abstraction” instance is bound to an MT ID?

I appreciate this is seeking to be published as Informational, however I’m not sure the document includes (any?) matters that are specific to NRPs. Consider, for example, Section 2, can we highlight please what is specific to NRPs? Thanks.

## Deviation from RFC 9543

I was stopped early in the document with statements such as:

CURRENT (abstract):
  This document describes how BGP-Link
  State (BGP-LS) with Multi-Topology (MT) can be used to distribute the
  information of SR based NRPs to the network controller when each NRP
                                                              ^^^^^^^^
  is associated with a separate logical network topology identified by
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  a Multi-Topology ID (MT-ID).

and then in the Introduction:

  In some network scenarios, the required number of NRPs could be
  small, each NRP can be associated with an separate logical topology,
  i.e., there is 1:1 mapping between an NRP and an Multi-Topology (MT)
  ID, and a set of dedicated or shared network resources is allocated
  to the NRP.

This 1:1 mapping assumption is clearly a simplification and does not reflect how the concept is defined in RFC 9543:

  Some NRP realizations may
  build NRPs with dedicated topologies, while other realizations may
  use a shared topology for multiple NRPs.

## If 1:1 (NRP==MT-ID) is assumed here, then a key aspect is how actual NRP resources are identified and bound to a topology ID. However, these matters seem to be out of scope.

Idem stitching mechanisms are also declared out of scope:

Section 2.2:
  Some mapping mechanism may be needed by the controller
  to match the MT-IDs of an inter-domain link in two directions, and
  concatenate the inter-domain topology of the NRP.  The detailed
  mechanism is out of the scope of this document.

# Not obvious causality effect: design assumptions

Section 2.2:
  In some network scenarios, for instance, an operator's network
  consists of multiple network parts, such as metro area networks,
  backbone networks, or data center networks, each part being a
  different AS.  Thus, there is a need to create NRPs which span
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  multiple ASes.
  ^^^^^^^^^^^^^^   

The causality effect is not given. In the same way that distinct QoS classes can be defined in each segment with appropriate mapping at the boundaries, I don’t see why a single NRP has to be defined here. Stitching can be in place, with handoff mechanisms.

Also, support of NRPs does not need to be provided in all segments. NRPs may be used in access-only, core-only.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-idr-bgpls-sr-vtn-mt-12, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022.*

Shepherd's writeup for version -07 and -10 by Susan Hares.
Shepherd's writeup amended for version -12 by Jeffrey Haas.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Call:  draft-ietf-idr-bgpls-sr-vtn-mt-07 (2/17 to 3/3/2025)
https://mailarchive.ietf.org/arch/msg/idr/7GqjhNBsHO7pprm2nkJfso-WSV8/

13 non-Authors supported this publication 
Zhuangshunwan (zhuangshunwan@huawei.com)
Nan Geng (gengnan@huawei.com)
Giuseppe Fioccola (giuseppe.fioccola@huawei.com)
Chen Ran (chen.ran@zte.com.cn)
Fan Zhang (fanzhang.chinatelecom@gmail.com)
Wei Wang (weiwang94@foxmail.com) - China Telcom
Aijun Wang (wangaijun@tsinghua.org.cn) -
Zhuo B (zhuo_b@foxmail.com)
Gyan Mishra (hayabusagsm@gmail.com)
linchangwang (linchangwang.04414@h3c.com)
Siyuan Teng (tengsy21@mails.tsinghua.edu.cn)
Chenhao Ma (henhao.M@outlook.com)
Lancheng (qinlc@mail.zgclab.edu.cn)
[13 non-authors, all with comments]

Change suggested in the review:
: Change 1: Aijun Wang (wangaijun@tsinghua.org.cn) - [acked for change in -08]
: One suggestion, it will be better for the reader to understand the concepts
: or procedures described in this document, if you can give one figure to
: illustrate the examples(cover intra-as and inter-as) for how to transfer the
: related NRP information via BGP-LS.

No such figure was crafted after version -07.  However, significant text was
added afterwards clarifying what specific information is carried in BGP-LS
and how it correlates using consistent configuration.

Gyan Mishra  offered comments in version -07 covering confusing references:
https://mailarchive.ietf.org/arch/msg/idr/_lrQ-TOTaXKvylLAMVxVorPoYow/

This was addressed in version -08.

In that message, Gyan further offered comments about link color mapping to NRP.
However, this procedure is not addressed or was not seen as applicable for
this informational draft and thus was not addressed by the authors.

Issues raised by Keyur Patel: https://mailarchive.ietf.org/arch/msg/idr/Nhcxz6A5SMbeQiJiMGlgAeoEGnY/
were addressed by version -12.

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

No controversy on this informational draft.
3 sets of comments comments discussed above.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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 appeals or extreme discomfort.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Not a protocol document, but a informational document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

IETF Early Reviews for:
a) RTG-DIR (Loa Anderson) - NITs, addressed by revisions (-10).
https://mailarchive.ietf.org/arch/msg/rtg-dir/h9EyqzLtZbARYQdWszUYcIE05vk/

b) OPS-DIR (Nagendra Kumar Nainar) - NITs addressed by revision -10
https://mailarchive.ietf.org/arch/msg/ops-dir/O4aJ8VKPK3iCWGtagu_QeOViw7I/

c) SEC-DIR (Corey Bonnell) - NITs addressed by revision -10
https://mailarchive.ietf.org/arch/msg/secdir/lSNkZk5uL2lgYlycRcI6UikuKgw/

d) Shepherd's final review of -10
https://mailarchive.ietf.org/arch/msg/idr/vVXC3X5xTdf4-NtmWK3_2GdBVsc/

e) Spring document (two normative documents)
https://mailarchive.ietf.org/arch/msg/spring/Q9-bcDgKXTOBYg988XhHK-oO40o/
(Alvaro Retana)

"draft-ietf-spring-resource-aware-segments is in the WGLC queue"

"We will be waiting on the outcome of the processing of
draft-ietf-spring-resource-aware-segments before moving on
draft-ietf-spring-sr-for-enhanced-vpn."

f) TEAS listing of the draft-ietf-teas-nrp-scalability as informative document.
https://mailarchive.ietf.org/arch/msg/teas/aYRlKFWIV0rOlni4np92vxtWYhI/

"We intend to progress draft-ietf-teas-nrp-scalability and
draft-ietf-teas-ns-ip-mpls together. The latter has some open issues that
need to be addressed before the WG can deem them both ready for WGLC. That
said, the documents are sufficiently mature, and we don't see any problems
with draft-ietf-teas-nrp-scalability being listed as an informational
document in the IDR document of interest."

g) LSR document (one normative reference)
  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-sr-vtn-mt/
The document is held with WGLC done pending on its normative reference to
the same SPRING documents - see email from LSR co-chair
https://mailarchive.ietf.org/arch/msg/lsr/VyzFaorWkvpy4vDp5-EaTZCFNeM/

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No additional formal review required.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Management structure (Yang) required for informational draft.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks required.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Shepherd's review prior to the WG LC:
https://mailarchive.ietf.org/arch/msg/idr/f4-WenPchd58tHvMKfxIh7dWrGE/

Shepherd's review post WG LC:
https://mailarchive.ietf.org/arch/msg/idr/vVXC3X5xTdf4-NtmWK3_2GdBVsc/

spring WG checks for normative document (see above)
lsr WG checks for normative document (see above)
teas WG checks for informative document (see above)

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

ART - not applicable
INT - not applicable
OPS - The shepherd believes the OPS-DIR Early review covered the topics
RTG - The shepherd believes the RTG-DIR Early review covered these topics
SEC - The shepherd  believes the BGP-LS base draft covers these issues for this informational draft.
Transport - Not applicable as far as the shepherd can tell.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational.  Why informational? Because it does not suggest any changes to on-the-wire in the BGP protocol


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. WG LC specified IPR for 3 authors. 
https://mailarchive.ietf.org/arch/msg/idr/7GqjhNBsHO7pprm2nkJfso-WSV8/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

4 authors: all with IPR statements.

Jie Dong (jie.dong@huawei.com)
https://mailarchive.ietf.org/arch/msg/idr/IvBHNRaRA8n5GuSYy6V7bo9Hrro/

Cong LI (licong_ct@163.com)
https://mailarchive.ietf.org/arch/msg/idr/VUdJW5LHvcuBBusdxmitwf6QGYI/

Robin (Zhenbin) Li (lizhenbin@huawei.com)
archive.ietf.org/arch/msg/idr/TNiWHMoLjbGW8gx1XWBiBgtcCyE/

Chongfeng Xie
https://mailarchive.ietf.org/arch/msg/idr/f4-WenPchd58tHvMKfxIh7dWrGE/


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

This text does not have any RFC-2119, but tool complains about this issue.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

all references are classified appropriately

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All Normative references are IETF documents (WG documents or RFCs)

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

[downref but not be added to the registry]
draft-ietf-lsr-isis-sr-vtn-mt

[downref that may potentially be added to the downref registry but have not yet reached the
stage of WGLC]
draft-ietf-spring-sr-for-enhanced-vp

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Please see point 5 (e) and (g) above. Of them, the maturity and readiness of
the spring WG documents below are somewhat unclear

draft-ietf-spring-resource-aware-segments (PS)
draft-ietf-spring-sr-for-enhanced-vp (informational).


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No changes to existing documents based on this document. 

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA changes request.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registries.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

The following Last Call announcement was sent out (ends 2025-09-17):

From: The IESG
To: IETF-Announce
CC: draft-ietf-idr-bgpls-sr-vtn-mt@ietf.org, idr-chairs@ietf.org, idr@ietf.org, ketant.ietf@gmail.com, shares@ndzh.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Applicability of Border Gateway Protocol - Link State (BGP-LS) with Multi-Topology (MT) for Segment Routing based Network Resource Partitions (NRPs)) to Informational RFC


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'Applicability of Border Gateway Protocol
- Link State (BGP-LS) with
  Multi-Topology (MT) for Segment Routing based Network Resource
  Partitions (NRPs)'
  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 2025-09-17. 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


  When Segment Routing (SR) is used for building Network Resource
  Partitions (NRPs), each NRP can be allocated with a group of Segment
  Identifiers (SIDs) to identify the topology and resource attributes
  of network segments in the NRP.  This document describes how BGP-Link
  State (BGP-LS) with Multi-Topology (MT) can be used to distribute the
  information of SR based NRPs to the network controller when each NRP
  is associated with a separate logical network topology identified by
  a Multi-Topology ID (MT-ID).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-sr-vtn-mt/



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

# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022.*

Shepherd's writeup for version -07 and -10 by Susan Hares.
Shepherd's writeup amended for version -12 by Jeffrey Haas.

Status: Awaiting Spring chairs and TEAS chair response.

Status: WG LC completed
## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Call:  draft-ietf-idr-bgpls-sr-vtn-mt-07 (2/17 to 3/3/2025)
https://mailarchive.ietf.org/arch/msg/idr/7GqjhNBsHO7pprm2nkJfso-WSV8/

13 non-Authors supported this publication 
Zhuangshunwan (zhuangshunwan@huawei.com)
Nan Geng (gengnan@huawei.com)
Giuseppe Fioccola (giuseppe.fioccola@huawei.com)
Chen Ran (chen.ran@zte.com.cn)
Fan Zhang (fanzhang.chinatelecom@gmail.com)
Wei Wang (weiwang94@foxmail.com) - China Telcom
Aijun Wang (wangaijun@tsinghua.org.cn) -
Zhuo B (zhuo_b@foxmail.com)
Gyan Mishra (hayabusagsm@gmail.com)
linchangwang (linchangwang.04414@h3c.com)
Siyuan Teng (tengsy21@mails.tsinghua.edu.cn)
Chenhao Ma (henhao.M@outlook.com)
Lancheng (qinlc@mail.zgclab.edu.cn)
[13 non-authors, all with comments]

Change suggested in the review:
: Change 1: Aijun Wang (wangaijun@tsinghua.org.cn) - [acked for change in -08]
: One suggestion, it will be better for the reader to understand the concepts
: or procedures described in this document, if you can give one figure to
: illustrate the examples(cover intra-as and inter-as) for how to transfer the
: related NRP information via BGP-LS.

No such figure was crafted after version -07.  However, significant text was
added afterwards clarifying what specific information is carried in BGP-LS
and how it correlates using consistent configuration.

Gyan Mishra  offered comments in version -07 covering confusing references:
https://mailarchive.ietf.org/arch/msg/idr/_lrQ-TOTaXKvylLAMVxVorPoYow/

This was addressed in verison -08.

In that message, Gyan further offered comments about link color mapping to NRP.
However, this procedure is not addressed or was not seen as applicable for
this informational draft and thus was not addressed by the authors.

Issues raised by Keyur Patel: https://mailarchive.ietf.org/arch/msg/idr/Nhcxz6A5SMbeQiJiMGlgAeoEGnY/
were addressed by version -12.

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

No controversy on this informational draft.
3 sets of comments comments discussed above.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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 appeals or extreme discomfort.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Not a protocol document, but a informational document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

IETF Early Reviews for:
a) RTG-DIR (Loa Anderson) - NITs, addressed by revisions (-10).
https://mailarchive.ietf.org/arch/msg/rtg-dir/h9EyqzLtZbARYQdWszUYcIE05vk/

b) OPS-DIR (Nagendra Kumar Nainar) - NITs addressed by revision -10
https://mailarchive.ietf.org/arch/msg/ops-dir/O4aJ8VKPK3iCWGtagu_QeOViw7I/

c) SEC-DIR (Corey Bonnell) - NITs addressed by revsion -10
https://mailarchive.ietf.org/arch/msg/secdir/lSNkZk5uL2lgYlycRcI6UikuKgw/

d) Shepherd's final review of -10
https://mailarchive.ietf.org/arch/msg/idr/vVXC3X5xTdf4-NtmWK3_2GdBVsc/

e) Spring document (two normative documents)
https://mailarchive.ietf.org/arch/msg/spring/Q9-bcDgKXTOBYg988XhHK-oO40o/
(Alvaro Retana)

"draft-ietf-spring-resource-aware-segments is in the WGLC queue"

"We will be waiting on the outcome of the processing of
draft-ietf-spring-resource-aware-segments before moving on
draft-ietf-spring-sr-for-enhanced-vpn."

f) TEAS listing of the draft-ietf-teas-nrp-scalability as informative document.
https://mailarchive.ietf.org/arch/msg/teas/aYRlKFWIV0rOlni4np92vxtWYhI/

"We intend to progress draft-ietf-teas-nrp-scalability and
draft-ietf-teas-ns-ip-mpls together. The latter has some open issues that
need to be addressed before the WG can deem them both ready for WGLC. That
said, the documents are sufficiently mature, and we don't see any problems
with draft-ietf-teas-nrp-scalability being listed as an informational
document in the IDR document of interest."

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No additional formal review reqwuired.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Management structure (Yang) required for informational draft.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks required.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Shepherd's review prior to the WG LC:
https://mailarchive.ietf.org/arch/msg/idr/f4-WenPchd58tHvMKfxIh7dWrGE/

Shepherd's review post WG LC:
https://mailarchive.ietf.org/arch/msg/idr/vVXC3X5xTdf4-NtmWK3_2GdBVsc/

spring WG checks for normative document (see above)
teas WG checks for informative document (see above).

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

ART - not applicable
INT - not applicable
OPS - The shepherd believes the OPS-DIR Early review covered the topics
RTG - The shepherd believes the RTG-DIR Early review covered these topics
SEC - The shepherd  believes the BGP-LS base draft covers these issues for this informational draft.
Transport - Not applicable as far as the shepherd can tell.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational.  Why informational? Because it does not suggest any changes to on-the-wire in the BGP protocol


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. WG LC specified IPR for 3 authors. 
https://mailarchive.ietf.org/arch/msg/idr/7GqjhNBsHO7pprm2nkJfso-WSV8/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

4 authors: all with IPR statements.

Jie Dong (jie.dong@huawei.com)
https://mailarchive.ietf.org/arch/msg/idr/IvBHNRaRA8n5GuSYy6V7bo9Hrro/

Cong LI (licong_ct@163.com)
https://mailarchive.ietf.org/arch/msg/idr/VUdJW5LHvcuBBusdxmitwf6QGYI/

Robin (Zhenbin) Li (lizhenbin@huawei.com)
archive.ietf.org/arch/msg/idr/TNiWHMoLjbGW8gx1XWBiBgtcCyE/

Chongfeng Xie
https://mailarchive.ietf.org/arch/msg/idr/f4-WenPchd58tHvMKfxIh7dWrGE/


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

This text does not have any RFC-2119, but tool complains about this issue.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Check the following informative references:
  [I-D.ietf-lsr-isis-sr-vtn-mt]
  [I-D.ietf-teas-nrp-scalability]

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All Normative references are IETF documents (WG documents or RFCs).

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Checks need to be made for status of the following normative: 
draft-ietf-spring-resource-aware-segments
draft-ietf-spring-sr-for-enhanced-vp
draft-ietf-teas-enhanced-vpn


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

This informational IDR document has a normative reference to:
draft-ietf-spring-resource-aware-segments (PS)
draft-ietf-spring-sr-for-enhanced-vp (informational).

See comments above.


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No changes to existing documents based on this document. 

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA changes request.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registries.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Awaiting the shepherd write-up cleanup to reflect the latest document and WG consensus status (i.e., remove issues that have been resolved in the WG). Capture only those issues/aspects where the consensus was rough or there was some controversy or threat of appeal.

# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022.*

Status: Awaiting Spring chairs and TEAS chair response.

Status: WG LC completed
## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Call:  draft-ietf-idr-bgpls-sr-vtn-mt-07 (2/17 to 3/3/2025)
https://mailarchive.ietf.org/arch/msg/idr/7GqjhNBsHO7pprm2nkJfso-WSV8/

13 non-Authors supported this publication 
Zhuangshunwan (zhuangshunwan@huawei.com)
Nan Geng (gengnan@huawei.com)
Giuseppe Fioccola (giuseppe.fioccola@huawei.com)
Chen Ran (chen.ran@zte.com.cn)
Fan Zhang (fanzhang.chinatelecom@gmail.com)
Wei Wang (weiwang94@foxmail.com) - China Telcom
Aijun Wang (wangaijun@tsinghua.org.cn) -
Zhuo B (zhuo_b@foxmail.com)
Gyan Mishra (hayabusagsm@gmail.com)
linchangwang (linchangwang.04414@h3c.com)
Siyuan Teng (tengsy21@mails.tsinghua.edu.cn)
Chenhao Ma (henhao.M@outlook.com)
Lancheng (qinlc@mail.zgclab.edu.cn)
[13 non-authors, all with comments]

Change suggested in the review:
Change 1: Aijun Wang (wangaijun@tsinghua.org.cn) - [acked for change in -08]
One suggestion, it will be better for the reader to understand the concepts
or procedures described in this document, if you can give one figure to
illustrate the examples(cover intra-as and inter-as) for how to transfer the
related NRP information via BGP-LS.

Change 2:  Gyan Mishra :
Where: Section 2.2 Inter-domain topology advertisements.
https://mailarchive.ietf.org/arch/msg/idr/_lrQ-TOTaXKvylLAMVxVorPoYow/

Confusing interaction with RFC9086 SR EPE only relevant for inter-domain SR
for SR-MPLS only and "SRv6 End.x Adj-sid can be used for the NRP specific
link.  Mapping to intra-domain MT ID that is an extension of inter-domain.

Question: RFC 9514 is BGP-LS SRv6 ext, and RFC 9085 is BGP-LS SR-MPLS ext.
Are the references to RFC9086 accurate?
I would only specify RFC 9085 SR EPE where the peer-adj-sid is mentioned.

2nd comment: If link coloring for NRP is consistent inter domain (no mapping required)
this scenario is not used.  Also, what procedures maps MT ID to NRP inter-domain.
Is MT ID to NRP ID stateless marking of VTN ID represented in NRP-ID or MT-ID.
Is this SR stateless packet marking of VTN ID or generic IETF (SR-MPLS or HBH TLV for SRv6)?

review by Keyur Patel: https://mailarchive.ietf.org/arch/msg/idr/Nhcxz6A5SMbeQiJiMGlgAeoEGnY/
Authors will:  Create a version 11 with changes.

Comments:
Keyur-Issue 1: section 1 paragraph 1, sentence starting out with"
old text:/ To meet the requirement of enhanced VPN services, a number
  of NRPs can be created, each with a subset of network resources
  allocated on network nodes and links in a customized topology of the
  physical network./
New text:/  To meet the requirement of enhanced VPN services, a number
  of NRPs can be created, each with a subset of network resources
  allocated on network nodes and links in a customized topology of the
  physical network. An exact mechanism to map NRP to one or group of enhanced VPN
  services are outside the scope of this document./

  [Chongfeng] Thanks for the proposed text. My suggestion is to make a little change to the last sentence: 
      The exact mechanism to map one or group of enhanced VPN services to a specific NRP is outside the scope of this document.

Keyur-Issue 2:
[Keyur] Do you need to worry about enforcing mechanism for Network Resource Partitioning or is that outside the scope of this document?
[Chongfeng] The enforcing mechanism for NRP is outside the scope of this document. We can clarify this in next revision.

Keyur Issue 3: Section 2.1: Do you envision the case where a given NRP supports multiple fabrics (SRv6 and SR MPLS)?
[Chongfeng] Good question, it is considered that in each domain, one data plane mechanism is selected for
an specific NRP. In different domains, a different data plane may be used for an inter-domain NRP. We can add some text to make this clearer.

Keyur Issue 4: Section 2.2: I think your referring to an ebgp case where these domains are under a common administration?
Is that correct? If so, can you explicitly call it out in second paragraph?
[Chongfeng] Yes, these domains should be under a common administration, or they belong to the same trusted domain as specified in section 8 of RFC 8402.

Keyur Issue 5:  Section 3: Last Paragraph: What is the guidance when the max bandwidth is exceeded? Is that out of scope for this doc? If so, can we call it out? Also, what exactly does the “advertisement of other TE    attributes in BGP-LS for NRP is for further study” mean?  Any error handling needs to be done or an implementation should silently ignore them.

[Chongfeng] To my understanding BGP-LS is just to report the information of the NRPs to the network controller, the validation of the information is done by the controller and is out of the scope of BGP-LS mechanism. As for the advertisement of other TE attributes, as they are based on existing TLVs, the advertisement and reception should be allowed, and the error handling in BGP-LS is the same as those defined in RFC 9552, while the usage of such information is out of the scope of BGP-LS.



1. Section 1:

An NRP could be used as the
  underlay to meet the requirement of one or a group of enhanced VPN
  services.  To meet the requirement of enhanced VPN services, a number
  of NRPs can be created, each with a subset of network resources
  allocated on network nodes and links in a customized topology of the
  physical network.

Consider:
An NRP could be used as the
  underlay to meet the requirement of one or a group of enhanced VPN
  services.  To meet the requirement of enhanced VPN services, a number
  of NRPs can be created, each with a subset of network resources
  allocated on network nodes and links in a customized topology of the
  physical network. An exact mechanism to map NRP to one or group of enhanced VPN
services are outside the scope of this document.

  [Chongfeng] Thanks for the proposed text. My suggestion is to make a little change to the last sentence: 
      The exact mechanism to map one or group of enhanced VPN services to a specific NRP is outside the scope of this document.

2. Do you need to worry about enforcing mechanism for Network Resource Partitioning or is that outside the scope of this document?
[Chongfeng] The enforcing mechanism for NRP is outside the scope of this document. We can clarify this in next revision.

3. Section 2.1: Do you envision the case where a given NRP supports multiple fabrics (SRv6 and SR MPLS)?
[Chongfeng] Good question, it is considered that in each domain, one data plane mechanism is selected for an specific NRP. In different domains, different data plane may be used for an inter-domain NRP. We can add some text to make this clearer.

4.  Section 2.2: I think your referring to an ebgp case where these domains are under a common administration? Is that correct? If so, can you explicitly call it out in second paragraph?

[Chongfeng] Yes, these domains should be under a common administration, or they belong to the same trusted domain as specified in section 8 of RFC 8402.

5. Section 3: Last Paragraph: What is the guidance when the max bandwidth is exceeded? Is that out of scope for this doc? If so, can we call it out? Also, what exactly does the “advertisement of other TE    attributes in BGP-LS for NRP is for further study” mean?  Any error handling needs to be done or an implementation should silently ignore them.

[Chongfeng] To my understanding BGP-LS is just to report the information of the NRPs to the network controller, the validation of the information is done by the controller and is out of the scope of BGP-LS mechanism. As for the advertisement of other TE attributes, as they are based on existing TLVs, the advertisement and reception should be allowed, and the error handling in BGP-LS is the same as those defined in RFC 9552, while the usage of such information is out of the scope of BGP-LS.


2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

No controversy on this informational draft.
3 sets of comments comments discussed above.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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 appeals or extreme disconmfort.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Not a protocol document, but a informational document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

IETF Early Reviews for:
a) RTG-DIR (Loa Anderson) - NITs, addressed by revisions (-10).
https://mailarchive.ietf.org/arch/msg/rtg-dir/h9EyqzLtZbARYQdWszUYcIE05vk/

b) OPS-DIR (Nagendra Kumar Nainar) - NITs addressed by revision -10
https://mailarchive.ietf.org/arch/msg/ops-dir/O4aJ8VKPK3iCWGtagu_QeOViw7I/

c) SEC-DIR (Corey Bonnell) - NITs addressed by revsion -10
https://mailarchive.ietf.org/arch/msg/secdir/lSNkZk5uL2lgYlycRcI6UikuKgw/

d) Shepherd's final review of -10
https://mailarchive.ietf.org/arch/msg/idr/vVXC3X5xTdf4-NtmWK3_2GdBVsc/

e) Spring document (two normative documents)
https://mailarchive.ietf.org/arch/msg/spring/Q9-bcDgKXTOBYg988XhHK-oO40o/
(Alvaro Retana)

"draft-ietf-spring-resource-aware-segments is in the WGLC queue"

"We will be waiting on the outcome of the processing of
draft-ietf-spring-resource-aware-segments before moving on
draft-ietf-spring-sr-for-enhanced-vpn."

f) TEAS listing of the draft-ietf-teas-nrp-scalability as informative document.
https://mailarchive.ietf.org/arch/msg/teas/aYRlKFWIV0rOlni4np92vxtWYhI/

"We intend to progress draft-ietf-teas-nrp-scalability and
draft-ietf-teas-ns-ip-mpls together. The latter has some open issues that
need to be addressed before the WG can deem them both ready for WGLC. That
said, the documents are sufficiently mature, and we don't see any problems
with draft-ietf-teas-nrp-scalability being listed as an informational
document in the IDR document of interest."

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No additional formal review reqwuired.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Management structure (Yang) required for informational draft.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks required.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Shepherd's review prior to the WG LC:
https://mailarchive.ietf.org/arch/msg/idr/f4-WenPchd58tHvMKfxIh7dWrGE/

Shepherd's review post WG LC:
https://mailarchive.ietf.org/arch/msg/idr/vVXC3X5xTdf4-NtmWK3_2GdBVsc/

spring WG checks for normative document (see above)
teas WG checks for informative document (see above).

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

ART - not applicable
INT - not applicable
OPS - The shepherd believes the OPS-DIR Early review covered the topics
RTG - The shepherd believes the RTG-DIR Early review covered these topics
SEC - The shepherd  believes the BGP-LS base draft covers these issues for this informational draft.
Transport - Not applicable as far as the shepherd can tell.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational.  Why informational? Because it does not suggest any changes to on-the-wire in the BGP protocol


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. WG LC specified IPR for 3 authors. 
https://mailarchive.ietf.org/arch/msg/idr/7GqjhNBsHO7pprm2nkJfso-WSV8/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

4 authors: all with IPR statements.

Jie Dong (jie.dong@huawei.com)
https://mailarchive.ietf.org/arch/msg/idr/IvBHNRaRA8n5GuSYy6V7bo9Hrro/

Cong LI (licong_ct@163.com)
https://mailarchive.ietf.org/arch/msg/idr/VUdJW5LHvcuBBusdxmitwf6QGYI/

Robin (Zhenbin) Li (lizhenbin@huawei.com)
archive.ietf.org/arch/msg/idr/TNiWHMoLjbGW8gx1XWBiBgtcCyE/

Chongfeng Xie
https://mailarchive.ietf.org/arch/msg/idr/f4-WenPchd58tHvMKfxIh7dWrGE/


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

This text does not have any RFC-2119, but tool complains about this issue.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Check the following informative references:
  [I-D.ietf-lsr-isis-sr-vtn-mt]
  [I-D.ietf-teas-nrp-scalability]

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All Normative references are IETF documents (WG documents or RFCs).

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Checks need to be made for status of the following normative: 
draft-ietf-spring-resource-aware-segments
draft-ietf-spring-sr-for-enhanced-vp
draft-ietf-teas-enhanced-vpn


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

This informational IDR document has a normative reference to:
draft-ietf-spring-resource-aware-segments (PS)
draft-ietf-spring-sr-for-enhanced-vp (informational).

See comments above.


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No changes to existing documents based on this document. 

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA changes request.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registries.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022.*

Status: Awaiting Spring chairs and TEAS chair response.

Status: WG LC completed
## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Call:  draft-ietf-idr-bgpls-sr-vtn-mt-07 (2/17 to 3/3/2025)
https://mailarchive.ietf.org/arch/msg/idr/7GqjhNBsHO7pprm2nkJfso-WSV8/

13 non-Authors supported this publication 
Zhuangshunwan (zhuangshunwan@huawei.com)
Nan Geng (gengnan@huawei.com)
Giuseppe Fioccola (giuseppe.fioccola@huawei.com)
Chen Ran (chen.ran@zte.com.cn)
Fan Zhang (fanzhang.chinatelecom@gmail.com)
Wei Wang (weiwang94@foxmail.com) - China Telcom
Aijun Wang (wangaijun@tsinghua.org.cn) -
Zhuo B (zhuo_b@foxmail.com)
Gyan Mishra (hayabusagsm@gmail.com)
linchangwang (linchangwang.04414@h3c.com)
Siyuan Teng (tengsy21@mails.tsinghua.edu.cn)
Chenhao Ma (henhao.M@outlook.com)
Lancheng (qinlc@mail.zgclab.edu.cn)
[13 non-authors, all with comments]

Change suggested in the review:
Change 1: Aijun Wang (wangaijun@tsinghua.org.cn) - [acked for change in -08]
One suggestion, it will be better for the reader to understand the concepts
or procedures described in this document, if you can give one figure to
illustrate the examples(cover intra-as and inter-as) for how to transfer the
related NRP information via BGP-LS.

Change 2:  Gyan Mishra :
Where: Section 2.2 Inter-domain topology advertisements.
https://mailarchive.ietf.org/arch/msg/idr/_lrQ-TOTaXKvylLAMVxVorPoYow/

Confusing interaction with RFC9086 SR EPE only relevant for inter-domain SR
for SR-MPLS only and "SRv6 End.x Adj-sid can be used for the NRP specific
link.  Mapping to intra-domain MT ID that is an extension of inter-domain.

Question: RFC 9514 is BGP-LS SRv6 ext, and RFC 9085 is BGP-LS SR-MPLS ext.
Are the references to RFC9086 accurate?
I would only specify RFC 9085 SR EPE where the peer-adj-sid is mentioned.

2nd comment: If link coloring for NRP is consistent inter domain (no mapping required)
this scenario is not used.  Also, what procedures maps MT ID to NRP inter-domain.
Is MT ID to NRP ID stateless marking of VTN ID represented in NRP-ID or MT-ID.
Is this SR stateless packet marking of VTN ID or generic IETF (SR-MPLS or HBH TLV for SRv6)?


2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

No controversy on this informational draft.
2 comments discussed above.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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 appeals or extreme disconmfort.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Not a protocol document, but a informational document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

IETF Early Reviews for:
a) RTG-DIR (Loa Anderson) - NITs, addressed by revisions (-10).
https://mailarchive.ietf.org/arch/msg/rtg-dir/h9EyqzLtZbARYQdWszUYcIE05vk/

b) OPS-DIR (Nagendra Kumar Nainar) - NITs addressed by revision -10
https://mailarchive.ietf.org/arch/msg/ops-dir/O4aJ8VKPK3iCWGtagu_QeOViw7I/

c) SEC-DIR (Corey Bonnell) - NITs addressed by revsion -10
https://mailarchive.ietf.org/arch/msg/secdir/lSNkZk5uL2lgYlycRcI6UikuKgw/

d) Shepherd's final review of -10
https://mailarchive.ietf.org/arch/msg/idr/vVXC3X5xTdf4-NtmWK3_2GdBVsc/

e) Spring document (two normative documents)
https://mailarchive.ietf.org/arch/msg/spring/Q9-bcDgKXTOBYg988XhHK-oO40o/
(Alvaro Retana)

"draft-ietf-spring-resource-aware-segments is in the WGLC queue"

"We will be waiting on the outcome of the processing of
draft-ietf-spring-resource-aware-segments before moving on
draft-ietf-spring-sr-for-enhanced-vpn."

f) TEAS listing of the draft-ietf-teas-nrp-scalability as informative document.
https://mailarchive.ietf.org/arch/msg/teas/aYRlKFWIV0rOlni4np92vxtWYhI/

"We intend to progress draft-ietf-teas-nrp-scalability and
draft-ietf-teas-ns-ip-mpls together. The latter has some open issues that
need to be addressed before the WG can deem them both ready for WGLC. That
said, the documents are sufficiently mature, and we don't see any problems
with draft-ietf-teas-nrp-scalability being listed as an informational
document in the IDR document of interest."

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No additional formal review reqwuired.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Management structure (Yang) required for informational draft.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks required.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Shepherd's review prior to the WG LC:
https://mailarchive.ietf.org/arch/msg/idr/f4-WenPchd58tHvMKfxIh7dWrGE/

Shepherd's review post WG LC:
https://mailarchive.ietf.org/arch/msg/idr/vVXC3X5xTdf4-NtmWK3_2GdBVsc/

spring WG checks for normative document (see above)
teas WG checks for informative document (see above).

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

ART - not applicable
INT - not applicable
OPS - The shepherd believes the OPS-DIR Early review covered the topics
RTG - The shepherd believes the RTG-DIR Early review covered these topics
SEC - The shepherd  believes the BGP-LS base draft covers these issues for this informational draft.
Transport - Not applicable as far as the shepherd can tell.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational.  Why informational? Because it does not suggest any changes to on-the-wire in the BGP protocol


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. WG LC specified IPR for 3 authors. 
https://mailarchive.ietf.org/arch/msg/idr/7GqjhNBsHO7pprm2nkJfso-WSV8/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

4 authors: all with IPR statements.

Jie Dong (jie.dong@huawei.com)
https://mailarchive.ietf.org/arch/msg/idr/IvBHNRaRA8n5GuSYy6V7bo9Hrro/

Cong LI (licong_ct@163.com)
https://mailarchive.ietf.org/arch/msg/idr/VUdJW5LHvcuBBusdxmitwf6QGYI/

Robin (Zhenbin) Li (lizhenbin@huawei.com)
archive.ietf.org/arch/msg/idr/TNiWHMoLjbGW8gx1XWBiBgtcCyE/

Chongfeng Xie
https://mailarchive.ietf.org/arch/msg/idr/f4-WenPchd58tHvMKfxIh7dWrGE/


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

This text does not have any RFC-2119, but tool complains about this issue.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Check the following informative references:
  [I-D.ietf-lsr-isis-sr-vtn-mt]
  [I-D.ietf-teas-nrp-scalability]

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All Normative references are IETF documents (WG documents or RFCs).

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Checks need to be made for status of the following normative: 
draft-ietf-spring-resource-aware-segments
draft-ietf-spring-sr-for-enhanced-vp
draft-ietf-teas-enhanced-vpn


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

This informational IDR document has a normative reference to:
draft-ietf-spring-resource-aware-segments (PS)
draft-ietf-spring-sr-for-enhanced-vp (informational).

See comments above.


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No changes to existing documents based on this document. 

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA changes request.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registries.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022.*

Status: Awaiting Spring chairs and TEAS chair response.

Status: WG LC completed
## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Call:  draft-ietf-idr-bgpls-sr-vtn-mt-07 (2/17 to 3/3/2025)
https://mailarchive.ietf.org/arch/msg/idr/7GqjhNBsHO7pprm2nkJfso-WSV8/

13 non-Authors supported this publication 
Zhuangshunwan (zhuangshunwan@huawei.com)
Nan Geng (gengnan@huawei.com)
Giuseppe Fioccola (giuseppe.fioccola@huawei.com)
Chen Ran (chen.ran@zte.com.cn)
Fan Zhang (fanzhang.chinatelecom@gmail.com)
Wei Wang (weiwang94@foxmail.com) - China Telcom
Aijun Wang (wangaijun@tsinghua.org.cn) -
Zhuo B (zhuo_b@foxmail.com)
Gyan Mishra (hayabusagsm@gmail.com)
linchangwang (linchangwang.04414@h3c.com)
Siyuan Teng (tengsy21@mails.tsinghua.edu.cn)
Chenhao Ma (henhao.M@outlook.com)
Lancheng (qinlc@mail.zgclab.edu.cn)
[13 non-authors, all with comments]

Change suggested in the review:
Change 1: Aijun Wang (wangaijun@tsinghua.org.cn) - [acked for change in -08]
One suggestion, it will be better for the reader to understand the concepts
or procedures described in this document, if you can give one figure to
illustrate the examples(cover intra-as and inter-as) for how to transfer the
related NRP information via BGP-LS.

Change 2:  Gyan Mishra :
Where: Section 2.2 Inter-domain topology advertisements.
https://mailarchive.ietf.org/arch/msg/idr/_lrQ-TOTaXKvylLAMVxVorPoYow/

Confusing interaction with RFC9086 SR EPE only relevant for inter-domain SR
for SR-MPLS only and "SRv6 End.x Adj-sid can be used for the NRP specific
link.  Mapping to intra-domain MT ID that is an extension of inter-domain.

Question: RFC 9514 is BGP-LS SRv6 ext, and RFC 9085 is BGP-LS SR-MPLS ext.
Are the references to RFC9086 accurate?
I would only specify RFC 9085 SR EPE where the peer-adj-sid is mentioned.

2nd comment: If link coloring for NRP is consistent inter domain (no mapping required)
this scenario is not used.  Also, what procedures maps MT ID to NRP inter-domain.
Is MT ID to NRP ID stateless marking of VTN ID represented in NRP-ID or MT-ID.
Is this SR stateless packet marking of VTN ID or generic IETF (SR-MPLS or HBH TLV for SRv6)?


2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

No controversy on this informational draft.
2 comments discussed above.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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 appeals or extreme disconmfort.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Not a protocol document, but a informational document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

IETF Early Reviews for:
a) RTG-DIR (Loa Anderson) - NITs, addressed by revisions (-10).
https://mailarchive.ietf.org/arch/msg/rtg-dir/h9EyqzLtZbARYQdWszUYcIE05vk/

b) OPS-DIR (Nagendra Kumar Nainar) - NITs addressed by revision -10
https://mailarchive.ietf.org/arch/msg/ops-dir/O4aJ8VKPK3iCWGtagu_QeOViw7I/

c) SEC-DIR (Corey Bonnell) - NITs addressed by revsion -10
https://mailarchive.ietf.org/arch/msg/secdir/lSNkZk5uL2lgYlycRcI6UikuKgw/

d) Shepherd's final review of -10
https://mailarchive.ietf.org/arch/msg/idr/vVXC3X5xTdf4-NtmWK3_2GdBVsc/

e) Spring document (two normative documents)
https://mailarchive.ietf.org/arch/msg/spring/Q9-bcDgKXTOBYg988XhHK-oO40o/
(Alvaro Retana)

"draft-ietf-spring-resource-aware-segments is in the WGLC queue"

"We will be waiting on the outcome of the processing of
draft-ietf-spring-resource-aware-segments before moving on
draft-ietf-spring-sr-for-enhanced-vpn."

f) TEAS listing of the draft-ietf-teas-nrp-scalability as informative document.
https://mailarchive.ietf.org/arch/msg/teas/aYRlKFWIV0rOlni4np92vxtWYhI/

"We intend to progress draft-ietf-teas-nrp-scalability and
draft-ietf-teas-ns-ip-mpls together. The latter has some open issues that
need to be addressed before the WG can deem them both ready for WGLC. That
said, the documents are sufficiently mature, and we don't see any problems
with draft-ietf-teas-nrp-scalability being listed as an informational
document in the IDR document of interest."

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No additional formal review reqwuired.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Management structure (Yang) required for informational draft.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks required.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Shepherd's review prior to the WG LC:
https://mailarchive.ietf.org/arch/msg/idr/f4-WenPchd58tHvMKfxIh7dWrGE/

Shepherd's review post WG LC:
https://mailarchive.ietf.org/arch/msg/idr/vVXC3X5xTdf4-NtmWK3_2GdBVsc/

spring WG checks for normative document (see above)
teas WG checks for informative document (see above).

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

ART - not applicable
INT - not applicable
OPS - The shepherd believes the OPS-DIR Early review covered the topics
RTG - The shepherd believes the RTG-DIR Early review covered these topics
SEC - The shepherd  believes the BGP-LS base draft covers these issues for this informational draft.
Transport - Not applicable as far as the shepherd can tell.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational.  Why informational? Because it does not suggest any changes to on-the-wire in the BGP protocol


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. WG LC specified IPR for 3 authors. 
https://mailarchive.ietf.org/arch/msg/idr/7GqjhNBsHO7pprm2nkJfso-WSV8/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

4 authors: all with IPR statements.

Jie Dong (jie.dong@huawei.com)
https://mailarchive.ietf.org/arch/msg/idr/IvBHNRaRA8n5GuSYy6V7bo9Hrro/

Cong LI (licong_ct@163.com)
https://mailarchive.ietf.org/arch/msg/idr/VUdJW5LHvcuBBusdxmitwf6QGYI/

Robin (Zhenbin) Li (lizhenbin@huawei.com)
archive.ietf.org/arch/msg/idr/TNiWHMoLjbGW8gx1XWBiBgtcCyE/

Chongfeng Xie
https://mailarchive.ietf.org/arch/msg/idr/f4-WenPchd58tHvMKfxIh7dWrGE/


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

This text does not have any RFC-2119, but tool complains about this issue.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Check the following informative references:
  [I-D.ietf-lsr-isis-sr-vtn-mt]
  [I-D.ietf-teas-nrp-scalability]

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All Normative references are IETF documents (WG documents or RFCs).

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Checks need to be made for status of the following normative: 
draft-ietf-spring-resource-aware-segments
draft-ietf-spring-sr-for-enhanced-vp
draft-ietf-teas-enhanced-vpn


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

This informational IDR document has a normative reference to:
draft-ietf-spring-resource-aware-segments (PS)
draft-ietf-spring-sr-for-enhanced-vp (informational).

See comments above.


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No changes to existing documents based on this document. 

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA changes request.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registries.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022.*

Status: Awaiting Spring chairs and TEAS chair response.

Status: WG LC completed
## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Call:  draft-ietf-idr-bgpls-sr-vtn-mt-07 (2/17 to 3/3/2025)
https://mailarchive.ietf.org/arch/msg/idr/7GqjhNBsHO7pprm2nkJfso-WSV8/

13 non-Authors supported this publication 
Zhuangshunwan (zhuangshunwan@huawei.com)
Nan Geng (gengnan@huawei.com)
Giuseppe Fioccola (giuseppe.fioccola@huawei.com)
Chen Ran (chen.ran@zte.com.cn)
Fan Zhang (fanzhang.chinatelecom@gmail.com)
Wei Wang (weiwang94@foxmail.com) - China Telcom
Aijun Wang (wangaijun@tsinghua.org.cn) -
Zhuo B (zhuo_b@foxmail.com)
Gyan Mishra (hayabusagsm@gmail.com)
linchangwang (linchangwang.04414@h3c.com)
Siyuan Teng (tengsy21@mails.tsinghua.edu.cn)
Chenhao Ma (henhao.M@outlook.com)
Lancheng (qinlc@mail.zgclab.edu.cn)
[13 non-authors, all with comments]

Change suggested in the review:
Change 1: Aijun Wang (wangaijun@tsinghua.org.cn) - [acked for change in -08]
One suggestion, it will be better for the reader to understand the concepts
or procedures described in this document, if you can give one figure to
illustrate the examples(cover intra-as and inter-as) for how to transfer the
related NRP information via BGP-LS.

Change 2:  Gyan Mishra :
Where: Section 2.2 Inter-domain topology advertisements.
https://mailarchive.ietf.org/arch/msg/idr/_lrQ-TOTaXKvylLAMVxVorPoYow/

Confusing interaction with RFC9086 SR EPE only relevant for inter-domain SR
for SR-MPLS only and "SRv6 End.x Adj-sid can be used for the NRP specific
link.  Mapping to intra-domain MT ID that is an extension of inter-domain.

Question: RFC 9514 is BGP-LS SRv6 ext, and RFC 9085 is BGP-LS SR-MPLS ext.
Are the references to RFC9086 accurate?
I would only specify RFC 9085 SR EPE where the peer-adj-sid is mentioned.

2nd comment: If link coloring for NRP is consistent inter domain (no mapping required)
this scenario is not used.  Also, what procedures maps MT ID to NRP inter-domain.
Is MT ID to NRP ID stateless marking of VTN ID represented in NRP-ID or MT-ID.
Is this SR stateless packet marking of VTN ID or generic IETF (SR-MPLS or HBH TLV for SRv6)?


2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

No controversy on this informational draft.
2 comments discussed above.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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 appeals or extreme disconmfort.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

IETF Early Reviews for:
1) RTG-DIR (Loa Anderson) - NITs, addressed by revisions (-10).
https://mailarchive.ietf.org/arch/msg/rtg-dir/h9EyqzLtZbARYQdWszUYcIE05vk/

2) OPS-DIR (Nagendra Kumar Nainar) - NITs addressed by revision -10
https://mailarchive.ietf.org/arch/msg/ops-dir/O4aJ8VKPK3iCWGtagu_QeOViw7I/

3) SEC-DIR (Corey Bonnell) - NITs addressed by revsion -10
https://mailarchive.ietf.org/arch/msg/secdir/lSNkZk5uL2lgYlycRcI6UikuKgw/

4) Shepherd's final review of -10

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No additional formal review reqwuired.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Management structure (Yang) required for informational draft.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks required.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Shepherd's review prior to the WG LC:
https://mailarchive.ietf.org/arch/msg/idr/f4-WenPchd58tHvMKfxIh7dWrGE/

Shepherd's review post WG LC:
https://mailarchive.ietf.org/arch/msg/idr/vVXC3X5xTdf4-NtmWK3_2GdBVsc/

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Need to check.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational.  Why? Because it does not suggest any on-the wire protocol
changes.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes WG LC specified IPR for 3 authors. 
https://mailarchive.ietf.org/arch/msg/idr/7GqjhNBsHO7pprm2nkJfso-WSV8/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

3 authors: all with IPR statements.

Jie Dong (jie.dong@huawei.com)
https://mailarchive.ietf.org/arch/msg/idr/IvBHNRaRA8n5GuSYy6V7bo9Hrro/

Cong LI (licong_ct@163.com)
https://mailarchive.ietf.org/arch/msg/idr/VUdJW5LHvcuBBusdxmitwf6QGYI/

Robin (Zhenbin) Li (lizhenbin@huawei.com)
archive.ietf.org/arch/msg/idr/TNiWHMoLjbGW8gx1XWBiBgtcCyE/

Chongfeng Xie
https://mailarchive.ietf.org/arch/msg/idr/f4-WenPchd58tHvMKfxIh7dWrGE/


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
[TBD]

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Check the following informative references:
  [I-D.ietf-lsr-isis-sr-vtn-mt]
  [I-D.ietf-teas-nrp-scalability]

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No all normative references are IETF WG documents.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Checks need to be made for status of the following normative: 
draft-ietf-spring-resource-aware-segments
draft-ietf-spring-sr-for-enhanced-vp
draft-ietf-teas-enhanced-vpn


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Checks need to be made for status of the following normative: 
draft-ietf-spring-resource-aware-segments
draft-ietf-spring-sr-for-enhanced-vp
draft-ietf-teas-enhanced-vpn

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No changes to existing documents based on this document. 

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA changes request.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registries.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022.*
Status: WG LC

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Call:  draft-ietf-idr-bgpls-sr-vtn-mt-07 (2/17 to 3/3/2025)
https://mailarchive.ietf.org/arch/msg/idr/7GqjhNBsHO7pprm2nkJfso-WSV8/

13 non-Authors supported this publication 
Zhuangshunwan (zhuangshunwan@huawei.com)
Nan Geng (gengnan@huawei.com)
Giuseppe Fioccola (giuseppe.fioccola@huawei.com)
Chen Ran (chen.ran@zte.com.cn)
Fan Zhang (fanzhang.chinatelecom@gmail.com)
Wei Wang (weiwang94@foxmail.com) - China Telcom
Aijun Wang (wangaijun@tsinghua.org.cn) -
Zhuo B (zhuo_b@foxmail.com)
Gyan Mishra (hayabusagsm@gmail.com)
linchangwang (linchangwang.04414@h3c.com)
Siyuan Teng (tengsy21@mails.tsinghua.edu.cn)
Chenhao Ma (henhao.M@outlook.com)
Lancheng (qinlc@mail.zgclab.edu.cn)
[13 non-authors, all with comments]

Change suggested in the review:
Change 1: Aijun Wang (wangaijun@tsinghua.org.cn) - [acked for change in -08]
One suggestion, it will be better for the reader to understand the concepts
or procedures described in this document, if you can give one figure to
illustrate the examples(cover intra-as and inter-as) for how to transfer the
related NRP information via BGP-LS.

Change 2:  Gyan Mishra :
Where: Section 2.2 Inter-domain topology advertisements.
https://mailarchive.ietf.org/arch/msg/idr/_lrQ-TOTaXKvylLAMVxVorPoYow/

Confusing interaction with RFC9086 SR EPE only relevant for inter-domain SR
for SR-MPLS only and "SRv6 End.x Adj-sid can be used for the NRP specific
link.  Mapping to intra-domain MT ID that is an extension of inter-domain.

Question: RFC 9514 is BGP-LS SRv6 ext, and RFC 9085 is BGP-LS SR-MPLS ext.
Are the references to RFC9086 accurate?
I would only specify RFC 9085 SR EPE where the peer-adj-sid is mentioned.

2nd comment: If link coloring for NRP is consistent inter domain (no mapping required)
this scenario is not used.  Also, what procedures maps MT ID to NRP inter-domain.
Is MT ID to NRP ID stateless marking of VTN ID represented in NRP-ID or MT-ID.
Is this SR stateless packet marking of VTN ID or generic IETF (SR-MPLS or HBH TLV for SRv6)?


2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

No controversy on this informational draft.
2 comments discussed above.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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 appeals or extreme disconmfort.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

IETF Early Reviews for:
1) RTG-DIR (Loa Anderson) - NITs, addressed by revisions (-10).
https://mailarchive.ietf.org/arch/msg/rtg-dir/h9EyqzLtZbARYQdWszUYcIE05vk/

2) OPS-DIR (Nagendra Kumar Nainar) - NITs addressed by revision -10
https://mailarchive.ietf.org/arch/msg/ops-dir/O4aJ8VKPK3iCWGtagu_QeOViw7I/

3) SEC-DIR (Corey Bonnell) - NITs addressed by revsion -10
https://mailarchive.ietf.org/arch/msg/secdir/lSNkZk5uL2lgYlycRcI6UikuKgw/

4) Shepherd's final review of -10

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No additional formal review reqwuired.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Management structure (Yang) required for informational draft.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks required.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Shepherd's review prior to the WG LC:
https://mailarchive.ietf.org/arch/msg/idr/f4-WenPchd58tHvMKfxIh7dWrGE/

Shepherd's review post WG LC:


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Need to check.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational.  Why? Because it does not suggest any on-the wire protocol
changes.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes WG LC specified IPR for 3 authors. 
https://mailarchive.ietf.org/arch/msg/idr/7GqjhNBsHO7pprm2nkJfso-WSV8/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

3 authors: all with IPR statements.

Jie Dong (jie.dong@huawei.com)
https://mailarchive.ietf.org/arch/msg/idr/IvBHNRaRA8n5GuSYy6V7bo9Hrro/

Cong LI (licong_ct@163.com)
https://mailarchive.ietf.org/arch/msg/idr/VUdJW5LHvcuBBusdxmitwf6QGYI/

Robin (Zhenbin) Li (lizhenbin@huawei.com)
archive.ietf.org/arch/msg/idr/TNiWHMoLjbGW8gx1XWBiBgtcCyE/

Chongfeng Xie
https://mailarchive.ietf.org/arch/msg/idr/f4-WenPchd58tHvMKfxIh7dWrGE/


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
[TBD]

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Check the following informative references:
  [I-D.ietf-lsr-isis-sr-vtn-mt]
  [I-D.ietf-teas-nrp-scalability]

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No all normative references are IETF WG documents.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Checks need to be made for status of the following normative: 
draft-ietf-spring-resource-aware-segments
draft-ietf-spring-sr-for-enhanced-vp
draft-ietf-teas-enhanced-vpn


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Checks need to be made for status of the following normative: 
draft-ietf-spring-resource-aware-segments
draft-ietf-spring-sr-for-enhanced-vp
draft-ietf-teas-enhanced-vpn


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No changes.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).



Checking IANA review (TBD)

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registries.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022.*
Status: WG LC

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Call:  draft-ietf-idr-bgpls-sr-vtn-mt-07 (2/17 to 3/3/2025)
https://mailarchive.ietf.org/arch/msg/idr/7GqjhNBsHO7pprm2nkJfso-WSV8/

13 non-Authors Individuals support
Zhuangshunwan (zhuangshunwan@huawei.com)
Nan Geng (gengnan@huawei.com)
Giuseppe Fioccola (giuseppe.fioccola@huawei.com)
Chen Ran (chen.ran@zte.com.cn)
Fan Zhang (fanzhang.chinatelecom@gmail.com)
Wei Wang (weiwang94@foxmail.com) - China Telcom
Aijun Wang (wangaijun@tsinghua.org.cn) -
Zhuo B (zhuo_b@foxmail.com)
Gyan Mishra (hayabusagsm@gmail.com)
linchangwang (linchangwang.04414@h3c.com)
Siyuan Teng (tengsy21@mails.tsinghua.edu.cn)
Chenhao Ma (henhao.M@outlook.com)
Lancheng (qinlc@mail.zgclab.edu.cn)
[13 non-authors, all with comments]

Change suggestsed in review:
Change 1: Aijun Wang (wangaijun@tsinghua.org.cn) - [acked for change in -08]
One suggestion, it will be better for the reader to understand the concepts
or procedures that described in this document, if you can give one figure to
illustrate the examples(cover intra-as and inter-as) for how to transfer the
related NRP information via BGP-LS.

Gyan Mishra :
Change 2: 
Where: Section 2.2 Inter domain topology advertisements.
https://mailarchive.ietf.org/arch/msg/idr/_lrQ-TOTaXKvylLAMVxVorPoYow/

Confusing interaction with RFC9086 SR EPE only relevant for inter-domain SR
for SR-MPLS only and "SRv6 End.x Adj-sid can be used for the NRP specific
link.  Mapping to intra-domain MT ID that is an extension of inter-domain.

Question: RFC 9514 is BGP-LS SRv6 ext and RFC 9085 is BGP-LS SR-MPLS ext.
Are the references to RFC9086 accurate?
I would only specify RFC 9085 SR EPE where the peer-adj-sid is mentioned.

2nd comment: If link coloring for NRP is consistent inter domain (no mapping required)
this scenario is not used.  Also, what procedures maps MT ID to NRP inter-domain.
Is MT ID to NRP ID stateless marking of VTN ID represented in NRP-ID or MT-ID.
Is this SR stateless packet marking of VTN ID or generic IETF (SR-MPLS or HBH TLV for SRv6)?


2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy on this informational draft.
2 comments discussed above.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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 appeals or extreme disconmfort. r

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No additional formal review reqwuired.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No Management structure (Yang) required for informational draft.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks required.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Shepherd's review prior to the WG LC:
https://mailarchive.ietf.org/arch/msg/idr/f4-WenPchd58tHvMKfxIh7dWrGE/

Shepherd's review post WG LC:


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Need to check.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Informational.  Why? Because it does not suggest any on-the wire protocol
changes.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes WG LC specified IPR for 3 authors. 
https://mailarchive.ietf.org/arch/msg/idr/7GqjhNBsHO7pprm2nkJfso-WSV8/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

3 authors: all with IPR statements.

Jie Dong (jie.dong@huawei.com)
https://mailarchive.ietf.org/arch/msg/idr/IvBHNRaRA8n5GuSYy6V7bo9Hrro/

Cong LI (licong_ct@163.com)
https://mailarchive.ietf.org/arch/msg/idr/VUdJW5LHvcuBBusdxmitwf6QGYI/

Robin (Zhenbin) Li (lizhenbin@huawei.com)
archive.ietf.org/arch/msg/idr/TNiWHMoLjbGW8gx1XWBiBgtcCyE/

Chongfeng Xie
https://mailarchive.ietf.org/arch/msg/idr/f4-WenPchd58tHvMKfxIh7dWrGE/


14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
[TBD]

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Check the following informative references:
  [I-D.ietf-lsr-isis-sr-vtn-mt]
  [I-D.ietf-teas-nrp-scalability]

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No all normative references are IETF WG documents.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Checks need to be made for status of the following normative: 
draft-ietf-spring-resource-aware-segments
draft-ietf-spring-sr-for-enhanced-vp
draft-ietf-teas-enhanced-vpn


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

Checks need to be made for status of the following normative: 
draft-ietf-spring-resource-aware-segments
draft-ietf-spring-sr-for-enhanced-vp
draft-ietf-teas-enhanced-vpn


19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No changes.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).



Checking IANA review (TBD)

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registries.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022.*
Status: WG LC

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Call:  draft-ietf-idr-bgpls-sr-vtn-mt-07 (2/17 to 3/3/2025)
https://mailarchive.ietf.org/arch/msg/idr/7GqjhNBsHO7pprm2nkJfso-WSV8/

13 non-Authors Individuals support
Zhuangshunwan (zhuangshunwan@huawei.com)
Nan Geng (gengnan@huawei.com)
Giuseppe Fioccola (giuseppe.fioccola@huawei.com)
Chen Ran (chen.ran@zte.com.cn)
Fan Zhang (fanzhang.chinatelecom@gmail.com)
Wei Wang (weiwang94@foxmail.com) - China Telcom
Aijun Wang (wangaijun@tsinghua.org.cn) -
Zhuo B (zhuo_b@foxmail.com)
Gyan Mishra (hayabusagsm@gmail.com)
linchangwang (linchangwang.04414@h3c.com)
Siyuan Teng (tengsy21@mails.tsinghua.edu.cn)
Chenhao Ma (henhao.M@outlook.com)
Lancheng (qinlc@mail.zgclab.edu.cn)
[13 non-authors, all with comments]

Change suggestsed in review:
Change 1: Aijun Wang (wangaijun@tsinghua.org.cn) - [acked for change in -08]
One suggestion, it will be better for the reader to understand the concepts
or procedures that described in this document, if you can give one figure to
illustrate the examples(cover intra-as and inter-as) for how to transfer the
related NRP information via BGP-LS.

Gyan Mishra :
Change 2: 
Where: Section 2.2 Inter domain topology advertisements.
https://mailarchive.ietf.org/arch/msg/idr/_lrQ-TOTaXKvylLAMVxVorPoYow/

Confusing interaction with RFC9086 SR EPE only relevant for inter-domain SR
for SR-MPLS only and "SRv6 End.x Adj-sid can be used for the NRP specific
link.  Mapping to intra-domain MT ID that is an extension of inter-domain.

Question: RFC 9514 is BGP-LS SRv6 ext and RFC 9085 is BGP-LS SR-MPLS ext.
Are the references to RFC9086 accurate?
I would only specify RFC 9085 SR EPE where the peer-adj-sid is mentioned.

2nd comment: If link coloring for NRP is consistent inter domain (no mapping required)
this scenario is not used.  Also, what procedures maps MT ID to NRP inter-domain.
Is MT ID to NRP ID stateless marking of VTN ID represented in NRP-ID or MT-ID.
Is this SR stateless packet marking of VTN ID or generic IETF (SR-MPLS or HBH TLV for SRv6)?



2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy on this informational draft.
2 comments discussed above.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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 appeals or extreme disconmfort. r

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Jie Dong (jie.dong@huawei.com)
https://mailarchive.ietf.org/arch/msg/idr/IvBHNRaRA8n5GuSYy6V7bo9Hrro/

Cong LI (licong_ct@163.com)
https://mailarchive.ietf.org/arch/msg/idr/VUdJW5LHvcuBBusdxmitwf6QGYI/

Robin (Zhenbin) Li (lizhenbin@huawei.com)
archive.ietf.org/arch/msg/idr/TNiWHMoLjbGW8gx1XWBiBgtcCyE/


Chongfeng Xie
https://mailarchive.ietf.org/arch/msg/idr/f4-WenPchd58tHvMKfxIh7dWrGE/



14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022.*
Status: WG LC

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Individuals support
Zhuangshunwan (zhuangshunwan@huawei.com)
Nan Geng (gengnan@huawei.com)
Giuseppe Fioccola (giuseppe.fioccola@huawei.com)
Chen Ran (chen.ran@zte.com.cn)
Fan Zhang (fanzhang.chinatelecom@gmail.com)
Wei Wang (weiwang94@foxmail.com) - China Telcom
Aijun Wang (wangaijun@tsinghua.org.cn) -
Zhuo B (zhuo_b@foxmail.com)
Gyan Mishra (hayabusagsm@gmail.com)
linchangwang (linchangwang.04414@h3c.com)
Siyuan Teng (tengsy21@mails.tsinghua.edu.cn)

Change suggestsed in review:
Change 1: Aijun Wang (wangaijun@tsinghua.org.cn) - [acked for change in -08]
One suggestion, it will be better for the reader to understand the concepts
or procedures that described in this document, if you can give one figure to
illustrate the examples(cover intra-as and inter-as) for how to transfer the
related NRP information via BGP-LS.

Gyan Mishra :
Change 2: 
Where: Section 2.2 Inter domain topology advertisements.
https://mailarchive.ietf.org/arch/msg/idr/_lrQ-TOTaXKvylLAMVxVorPoYow/

Confusing interaction with RFC9086 SR EPE only relevant for inter-domain SR
for SR-MPLS only and "SRv6 End.x Adj-sid can be used for the NRP specific
link.  Mapping to intra-domain MT ID that is an extension of inter-domain.

Auestion: RFC 9514 is BGP-LS SRv6 ext and RFC 9085 is BGP-LS SR-MPLS ext.
Are the references to RFC9086 accurate?
I would only specify RFC 9085 SR EPE where the peer-adj-sid is mentioned.

2nd comment: If link coloring for NRP is consistent inter domain (no mapping required)
this scenario is not used.  Also, what procedures maps MT ID to NRP inter-domain.
Is MT ID to NRP ID stateless marking of VTN ID represented in NRP-ID or MT-ID.
Is this SR stateless packet marking of VTN ID or generic IETF (SR-MPLS or HBH TLV for SRv6)?



2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy on this informational draft.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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.)

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Jie Dong (jie.dong@huawei.com)
https://mailarchive.ietf.org/arch/msg/idr/IvBHNRaRA8n5GuSYy6V7bo9Hrro/

Cong LI (licong_ct@163.com)
https://mailarchive.ietf.org/arch/msg/idr/VUdJW5LHvcuBBusdxmitwf6QGYI/

Robin (Zhenbin) Li (lizhenbin@huawei.com)
archive.ietf.org/arch/msg/idr/TNiWHMoLjbGW8gx1XWBiBgtcCyE/


Chongfeng Xie
https://mailarchive.ietf.org/arch/msg/idr/f4-WenPchd58tHvMKfxIh7dWrGE/



14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/