# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022.*
## 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?
Strong consensus with good discussions.
https://mailarchive.ietf.org/arch/msg/idr/PndHjsj0nj6fFZ97inb8iz8_Qvk/https://mailarchive.ietf.org/arch/msg/idr/0dL1E-C74DUgkjyOlvFStqingfg/
2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?
No. The discussion was active and provided good refinements to the draft.
https://mailarchive.ietf.org/arch/browse/idr/?q=draft-ietf-idr-sr-bgp-ls-sr-policy
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
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)?
2 implementations: See
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-te-lsp-distribution
One implementation does not have PCE and BGP co-resident, so it does not
transmit the code to indicate the "reported via PCE" code. The
Shepherd does not feel this should hold up standardization.
Both Huawei and Cisco have implemented nine of the TLVs.
Cisco has implemented all 18 of the TLVs. One group of
TLVs not implemented by Huawei are the Constraint related
TLVs (SR CP Constraints, SR AFfinity Constraint, SR SRLG Constraint,
SR Bandwidth Constraint, SR Disjoint Group Constraint,
SR Bidirectional Group Constraint, SR Metric Sontraint).
The second group is the SR Segment list Bandwidth and the
SR Segment list Bandwidth.
#Shepherd review page:
https://wiki.ietf.org/group/idr/Shepherd-SR-BGP-LS/BGP-LS-SR/bgp-ls-sr-policy
[you also go through the IDR wiki - See BGP-LS and SR Shepherd REviews)
Shepherd Reviews on SR and BGP-LS drafts
[https://wiki.ietf.org/group/idr/Shepherd-SR-BGP-LS]
## Additional Early Direcorate Reviews Reviews
RTG-DIR (Joel Halpern): Ready with a few comments
SEC-DIR (Net Smith, 2/5): Ready with Nits
GEN-ART (Meral Shirazipour, 2/21) Ready
OPS-DIR (Tina Tsou): Has Issues regarding Scaling - addressed by Ketan
https://mailarchive.ietf.org/arch/msg/idr/PRhis-VEcyVEjQItu2VUYNLtj0Y/
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.
The BGP-LS for SR technologies closely interact with the spring and the srv6ops
WG. These WG were directly queried on 11/10/2024.
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.
The need for Yang models modeling this work has been added to:
https://wiki.ietf.org/group/idr/BGP-Model-Features
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]?
Not applicable since this is not a Yang model.
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.
Not applicable.
## 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?
Links to Shepherd's report is on IDR wiki
https://wiki.ietf.org/group/idr/Shepherd-SR-BGP-LS/BGP-LS-SR/bgp-ls-sr-policy
Mail lists:
See Shepherd's review prior to WG LC:
https://mailarchive.ietf.org/arch/msg/idr/DLfvkhT7HOClFSfUzFNQ9z8bSFc/
See Shepherd's review of -08/
https://mailarchive.ietf.org/arch/msg/idr/JW8IIxVTMer5-Qq7ld5ZCHXQ2sk/
Please note the Shepherd requested AD review of 3 items:
https://mailarchive.ietf.org/arch/msg/idr/JW8IIxVTMer5-Qq7ld5ZCHXQ2sk/
and
https://mailarchive.ietf.org/arch/msg/idr/CvA1crVQJVfTDl2yvjNp_8kcXRo/
Ketant's viewpoint is that
#15 = Maximum that fits in packet resolved by RFC9552/section 5.3
#18 and #30 - Ketan believes the metric types are not being consumed in
BGP-LS. As new IANA code points are added, the implementers will know what is
range and what is not.
John Scudder agreed with this viewpoint:
https://mailarchive.ietf.org/arch/msg/idr/bje6-B888d6Eykk7Q7IJ-GMM7wA/
RTG-DIR review (Joel Halpern, and OK)
https://mailarchive.ietf.org/arch/msg/idr/iuD4n-9b4-dMI1SQa1vkCPK7nfA/
OPS-DIR review (Tina Tsou, Has Issues - Resolved )
https://mailarchive.ietf.org/arch/msg/idr/PRhis-VEcyVEjQItu2VUYNLtj0Y/
Ketan's response indicates that explanations ask for repetition of information
in RFC9552 and RFC95256. For consumer validation, the BGP-LS restates that
consumer of the BGP-LS information is outside the scope of BGP. [The Shepherd
has been through these issues with the authors, but the OPS-AD should be warned
to review this OPS-DIR review during the AD evaluation. Better an early
discussion that a late discovery.]
GEN-DIR (2/5, Ned Smith): Ready with NITS
https://mailarchive.ietf.org/arch/msg/secdir/f3JFqPR978Jq9_ypAT1Dn2UlxaE/
- Ned Smith noted 3 conventions unique to the BGP-LS work.
Ketan explained these conventions in his response.
SEC-DIR Review (2/26, Meral Shirazipour): Ready with NITs
- Only editoral
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?
Yes - a few points from section 9 are summarized for Routing and Security lists:
This is an extension of BGP-LS to manage/monitor SR policy for a truster SR
domain [RFC8402]. It states: a) SR operates within a trusted SR domain
[RFC8402), and the security considerations apply to this document. b)
Controllers and application services using the BGP-LS information are expected
to be within the trusted SR domain, c) SR Policy data is critical data "that
constitutes a risk to [the] confidentiality of mission-critical or commercially
sensitive" data.
As always, BGP-ls traffic needs to be isolated from other BGP traffic (due to
load)
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?
Proposed Standard:
Why Proposed standard: This draft augments proposed standards for
BGP-LS and SR in BGP (RFC9552, RFC9514, RFC9086).
Adding values to the following existing registries for BGP-LS:
a) BGP-LS NLRI-Types
b) BGP-LS Protocol-IDs
c) BGP-LS NLRI and Attribute TLV
The following registry related to BGP-LS and PCEP was
requested to be create: SR Policy Protocol Origin
The following new registries are created:
1.) BGP-LS SR Segment Descriptors
2) BGP-LS SR Policy Metric Type
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.
Ketan Talaulikar
https://mailarchive.ietf.org/arch/msg/idr/XNMFZ7_-GYwEVzALZF9aTylLWQQ/
Jie Dong:
https://mailarchive.ietf.org/arch/msg/idr/iuBOyS4Yuuiq1fgvbSZtPiHbLW4/
Jeff Tantsura
https://mailarchive.ietf.org/arch/msg/idr/9h3iYa7fzYE3lvNcOaeOeheBoiM/
Clarence Filsfils
https://mailarchive.ietf.org/arch/msg/idr/QaTiyYvGE5Yd6w1_JW_fz94ZpZs/
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.
Yes.
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.)
NITs check - just
https://mailarchive.ietf.org/arch/msg/idr/LyA6VOHdEJEuZjaV4HRaXnd8QzU/
NIT Check response:
https://mailarchive.ietf.org/arch/msg/idr/BwcU5Bmxd_7RyULcwQAcG5uTUmg/
15. Should any informative references be normative or vice-versa? See the [IESG
Statement on Normative and Informative References][16].
No.
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 are 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.
No.
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?
No.
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.
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]).
See IANA's early review of the document:
https://mailarchive.ietf.org/arch/msg/idr/Xw9HfBTseSO_2dfV7UDRwoqKNAM/
Adding values to the following existing registries
a) BGP-LS NLRI-Types
b) BGP-LS Protocol-IDs
c) BGP-LS NLRI and Attribute TLV
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. SR Policy Protocol Origin registry - a new registry under "Segment Routing"
with an allocation policy is "Expert Review" [RFC8126] using the guidelines for
Designated Experts as specified in [RFC9256].
2. SR Segment Descriptor Types - a new registry under "Border Gateway Protocol
- Link State (BGP-LS) Parameters" registry group with an allocation policy is
"Expert Review" [RFC8126] using the guidelines for Designated Experts as
specified in [RFC9256].
3. BGP-LS SR Policy Metric Types - a new registry under "Border Gateway
Protocol - Link State (BGP-LS) Parameters" registry group with an allocation
policy is "Expert Review" [RFC8126] using the guidelines for Designated Experts
as specified in [RFC9256].
[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://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/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/