# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022. [see RFC4858 for details]
Shepherd's note to AD note: Please review the security section first and
consider the issues for both CAR and CT.
## 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?
The CT progression after adoption is tracked on both the IDR Wiki
and the IDR github repository: ietf-wg-idr/draft-ietf-idr-bgp-ct
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues
Post 2nd WG LC Shepherd's review of -26.txt
https://mailarchive.ietf.org/arch/msg/idr/7PIQx2nE0Y4d-lR7bIpTPL_TMR0/
Summary of calls: (in reverse time order)
2nd WG LC: 2/16/2024 to 3/1/2024
https://mailarchive.ietf.org/arch/msg/idr/Ud2coGDvdXYy7x-SHPSK2Onwjx4/
Status: Consensus on publication of draft-ietf-idr-bgp-ct and
draft-ietf-idr-bgp-ct-srv6https://mailarchive.ietf.org/arch/msg/idr/oNY5gAcE21y1bke6tBzeb76uVo4/https://mailarchive.ietf.org/arch/msg/idr/rJC4O726QqUoDEqFTffOF9EvX_U/
----
1st WG LC: draft-ietf-idr-bgp-ct-09.txt (6/26/2023 to 7/17/2023
https://mailarchive.ietf.org/arch/msg/idr/KYZbOsg2y4jcOfjV31pee5uhMjQ/
extension to 7/28:
https://mailarchive.ietf.org/arch/msg/idr/Qr8GhdlEi8viaZxOCaWii3cA51s/
Extension to 8/01:
https://mailarchive.ietf.org/arch/msg/idr/fC--NIU7VlyOjmNJwIcsXhXFvSk/ status:
No consensus reached
The shepherd's write-up on this topic is available on the IDR wiki
https://wiki.ietf.org/e/en/group/idr/CT-WGLC
Email message notifying the WG of 1 WG LC Shepherd's report:
https://mailarchive.ietf.org/arch/msg/idr/klBUhMe9AsdflYhIYVEhSIps_lg/
---------
Adoption call results: (as part of status)
https://mailarchive.ietf.org/arch/msg/idr/0V6pBTQyCmh3t3h9cMqxZ3N0s7Q/
Adoption call: Time: 7/6/2022 to 7/27/2022 in 3 mail threads.
Part 1 of CAR/CT Adoption call (7/6 to 7/27): Informational Questions
https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/
Part 2 of CAR/CT Adoption call (7/6 to 7/27): Adoption call
https://mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/
Part 3 of CAR/CT Adoption call (7/14 to 7/27) - Please note that Part 3 has a
specific format for posting.
https://mailarchive.ietf.org/arch/msg/idr/fTFYwF54WRHcj7PDt2t7sOQg6vo/
This adoption call was preceded by the following:
Email Discussion before IETF-113
https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/
Note: The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on
March 21, 2022, that for route resolution and route origination/propagation,
BGP-CAR and BGP-CT are functionally identical but operationally different.
Presentations from IETF-108 to IETF-113
IDR interim on January 24, 2022
(https://datatracker.ietf.org/meeting/interim-2022-idr-02/session/idr)
2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?
Rough Adoption decision:
The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March
21, 2022, that for route resolution and route origination/propagation, BGP-CAR
and BGP-CT are functionally identical but operationally different.
IDR WG could not come to a consensus on CAR vs. CT. IDR Chairs elected to adopt
both CAR and CT drafts as experimental drafts. Experience in the market
place will help determine which is better operationally.
Rough 1st WG LC of CAR/CT: The IDR WG LC for CAR and CT found the
editors/authors/contributors of CAR commenting on the CT draft (Just as CT
authors commented on CAR draft). In some ways, this lively debate helped find
problems in the specifications.
2nd WG LC of CAR/CT: This WG LC did not have a lot of
CAR/CT editor discussions because the IDR Shepherding Chair had
a private discussion between editors prior to the 2nd WG LC.
During 2nd WG LC: Concern on Split of CT drafts into 3 drafts:
https://mailarchive.ietf.org/arch/msg/idr/29CYvVl0RnW0hJSU3il3p_cqt80/
Robert Raszuk raised a Concern regarding the splitting of the
CT draft into three parts (draft-ietf-idr-bgp-ct, draft-ietf-idr-bgp-ct-srv6,
and draft-ietf-idr-bgp-fwd-rr). Robert objected to the draft-ietf-idr-bgp-fwd-rr
being a WG draft. The IDR chairs felt the text was in draft-ietf-idr-bgp-ct
since version -09, so Robert's concerns about being surprised as
WG draft was not justified. However, it does point to the value of
the IDR chairs splitting this work out of the draft-ietf-idr-bgp-ct draft.
------
Dependencies on Spring:
a) Functional dependency - caused only theoretical scaling results
Due to a lack of adoption of the Spring Requirements document
draft-hr-spring-intentaware-routing-using-color-03, this WG
Shepherd allowed the scaling results to be theoretical without proof in CT.
b) Normative dependency on
draft-ietf-idr-salih-spring-srv6-inter-domain-sids-04. There is a normative
dependency on an individual draft that is waiting for adoption. The Spring
chairs have been notified that IDR draft-ietf-idr-bgp-ct-srv6 has normative
dependencies on draft-ietf-idr-salih-spring-srv6-inter-domain-sids.
Dependencies with PCE
Dhruv Dhody reviewed the interactions with PCE drafts.
He sent comments to the CT authors. CT authors updated their drafts with
changes.
Dependencies with BESS:
BESS chairs were queried about reviewing the CAR and CT drafts.
No direct information was received.
-----
Alternatives for SRv6 without CAR or CT.
A third draft (draft-ietf-idr-cpr-00) was adopted as an informational draft.
This informational draft provides a way to encode intent for
SRv6 by operational practices rather than a new protocol.
## Directorate Reviews: (tracked by Datatracker) with comments from shepherd
RTG-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-09 (Med Boucadair)- status: has issues,
excellent review
https://mailarchive.ietf.org/arch/msg/rtg-dir/aawFfvd29zERSBK4ydDDhxEQGRw Early
Review of draft-ietf-idr-bgp-ct-18 (Jonathan Hardwick) - status: has nits, good
review
https://mailarchive.ietf.org/arch/msg/rtg-dir/FLGmC0-ufqPsZpH_LmgL2eWmWhY
Shepherd's follow-up: All NITs resolved by -30
OPS-DIR reviews:
Early Review of draft-ietf-idr-bgp-ct-12 (Bo Wu) - status: Has issues, Quality:
good review, 4 issues mentioned
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-12-opsdir-early-wu-2023-08-03/
Early Review of draft-ietf-idr-bgp-ct-18 (Bo Wu) - status: has nits, Quality:
good review, 2nd review by the same reviewer as -12
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-19-opsdir-early-wu-2024-01-05/
Shepherd's review: All Nits resolved by -30.
SEC-DIR Review:
Authors resolved in -30, except for NIT
email link:
https://mailarchive.ietf.org/arch/msg/idr/fYulGchhf6oWPWhVWHxqx6WNupI/ github:
assigned github issue #69 github
link:https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69 Status:
Shepherd awaiting clarification email (sent 4/9)) Resolved by -32, but AD
should look at the github issue #69 (closed issue)
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69
TSV-Review: (due date 3/6/2024) - On the Right Track.
https://mailarchive.ietf.org/arch/msg/tsv-art/hml_nr-BAbzXk7RnKCCy-EVXLuw/
TSV-DIR:
From the viewpoint of the transport area, there are two important points that
need to be discussed when considering such tunnels:
1) MTU problems if the tunnel configurations differ, and
2) DSCP issues if DSPC is used to provide non-best effort services.
Status: -30 contained fixes for TSV-DIR, but no 2nd review.
Shepherd's comment for TSV-DIR: Please look at this draft from the viewpoint of
having intent (color) aware customer traffic forwarded over a VPN overlay
(tunnels) that forwarded over a set of intent (color) aware underlay of
tunnels. Please consider the problems with tunnels in your review of this text.
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.)
Andrew mentioned he received feedback that there would be discomfort
if the CAR and CT do not progress to the Experimental simultaneously.
See Andrew Alston for additional details.
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)?
Implementation report:
https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-bgp-ct
Implementation of CT: Juniper, Freertg
Implementation of CT-srv6: (TBD)
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.
Reviews requested from PCE, Spring, and BESS before 2nd WG LC.
Received reviews from PCE: CT updated based on feedback (missing link in IDR
Mail) Received feedback from Spring chairs (Alvaro Retana)
The following drafts were in the option queue:
draft-hr-spring-intentaware-routing-using-colordraft-salih-spring-srv6-inter-domain-sids-04 (ct-srv6)
Nothing was received from BESS.
RTG-DIR reviews: 2 early reviews - (-18) "has nits"
OPS-DIR reviews: 2 early reviews - (-19) "has nits"
SEC-DIR reviews: 2 early reviews - (-19) 6 problems + 4 questions (must be
resolved) TSV-DIR review: 1 early review requested - no response. IANA Early
review: IANA early review of draft-ietf-idr-bgp-ct-27 IANA section.
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 requirement for formal review (MIB, Yang, Media type, and URI)
A yang module for CT will be added to the list of Yang modules to create for
BGP.
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 Yang in the document
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 checking
## 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?
Checks completed:
1) Pre-Adoption by Jeff Haas and discussion among chairs
2) Careful Adoption review resulted in a list of issues that needed to be
resolved:
(https://wiki.ietf.org/group/idr/CAR-CTAdoption)
3) Adoption call issues added to github for draft-ietf-idr-bgp-ct-27
(https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)
4) 1st WG LC -
Prior to 1st WG LC: Shepherd verified that issues were addressed
and early Early Directorate reviews requested,
1st WG LC: Shepherd report written
(see https://wiki.ietf.org/group/idr/CT-WGLC and
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)
Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.
5) 2nd WG LC
Prior to 2nd WG LC:
a) Shepherd verified that issues raised in 1st WG LC were addressed.
b) Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff
Haas. c) IDR Chair team resolutions were made - via email and meetings
of
technical issues.
d) Early reviews requested (RTG-DIR, OPS-DIR, SEC-DIR, and TSV-DIR)
open reviews: resolution of SEC-DIR and lack of TSV-DIR
d) Meeting with CAR and CT editor teams during 2nd WGLC
e) two interims in 2024 - January 29 and February 26 - review status
6) Post WG LC
a) Shepherd reports with editorial nits [resolved]
b) Shepherd report loaded into github as issues [Resolved]
c) Review issues with document editors before -27 submission [Resolved]
b) IANA review of -27 requested. [pending]
c) github issue loaded with Security Directorate review comments
7)Final Checks
a) Response from IANA review of -27
b) Response from SEC-DIR resolution check
c) final NITS check
d) RFC9012 issues
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? All items addressed, but these are the key points
RTG-DIR and OPS-IDR review examines whether these new "intent-aware" (color)
are able to be created and used. The early review cycles ended with "OK with
NITs". The NITs have been address (see github for tracking of NITs).
The Transport area review (TSV-DIR) was only looking at whether the network
was on the right path to allow intents to create "intent" (color)
network-wide paths of a certain type. Applications through transport layers
are the ones to signal a particular intent and need. The desired answer
from TSV-DIR is "on the right track".
SEC-DIR review of CT and CTv6 mentioned that these drafts look to
BGP security solutions (BGPsec and Origin validation) to provide additional
security without giving the details on the solutions. During an
investigation of the BGPsec a few things turned up about BGPSec. The
shepherd notes that RFC8374 points out that BGPsec (RFC8205) only included
the AFI in the "hash" to resolve a problem (see sections 2.2.1 and 6.2.1).
Section 2.2.1 includes the AFI/SAFI in Figure 8, but may assume only IPv4
(AFI=1) and IPv6 (AFI=2).
Due to this unclear text, both BGP intent-based solutions (CAR and CT)
merely state that BGPsec and Origin Validation could be extended. It is
beyond the scope of these individual drafts to raise the wider issue of
BGPsec applications for many new AFI/SAFIs. It is an an issues that needs
addressing by the IDR WG.
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?
Experimental draft. Why? IDR cannot settle on a single solution for
Intent-based (Color) routing. The top 2 solutions are forwarded as
experimental drafts to allow operational deployment to give feedback.
Do all Datatracker state attributes correctly reflect this intent? Yes .
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.
Editors:
2nd WG LC -03
Kaliraj Vairavakkali (kaliraj@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/ZL7tOk3fgqeIRM5dfKfx_GbIh2w/
Natrajan Venkataraman (natv@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/eh3IdjyMjJVQSwOx2CD95iKg1-4/
CoAuthors:
Reshma Das (dreshma@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/Ei8WY3sVYAhnECr1w40Y8C5zQ-Y/
Israel Means (israel.means@att.com)
https://mailarchive.ietf.org/arch/msg/idr/iniOhZ1BknkBhe2l8DYL5aL_lGk/
Csaba Mates (ietf@nop.hu)
https://mailarchive.ietf.org/arch/msg/idr/NSxyfq98238jOIllMgIrBF54aeg/
Deepak J. Gowda (dgowda@extremenetworks.com) [2nd WG LC]
https://mailarchive.ietf.org/arch/msg/idr/FWf7jsy7mFJDiW3stAWeJ_DU0oU/
Contributors:
Balaji Rajagoplan (balajir@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/SfJQVDClw7y8vXYoG8wlLKRgyLQ/
Rajesh M (mrajesh@juniper.net)
https://mailarchive.ietf.org/arch/msg/idr/4T2BDGnaZUmtWUPjFVIOAFL-ZoI/
Chaitanya Yadlapalli (cy098d@att.com)
https://mailarchive.ietf.org/arch/msg/idr/M1c3trnvMiVn3_QQU9FqbkuvHA0/
Mazen Khaddam (mazen.khaddam@cox.com)
https://mailarchive.ietf.org/arch/msg/idr/lhBotT08JzICX-uPUfhMUSA7uzc/
Rafal Jan Szarecki (Google)
https://mailarchive.ietf.org/arch/msg/idr/r09fylzRRgssJqDoQnhy66qCr-g/
Xiaohu Xu (Captialonline) [from 1st WG LC]
https://mailarchive.ietf.org/arch/msg/idr/DBuobWpmj_ce0IOUWDTZU7m095E/
2nd WG LC
https://mailarchive.ietf.org/arch/msg/idr/Uh39xPb20FTsmORAjgRlce8bwfc/
Contributor for [-12] missing in [-27]
Gyan Mishra (gyan.s.mishra@verizon.com) - dropped as of [-11]
before 1st WG LC. Missing IPR statement.
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.
2 editors on front page.
All IPR statements good for -27 except for Xiahou Xu.
issue with Gyan Mishra - no longer contributor after -11
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.)
[pending] NITS - see github reference
https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/72
15. Should any informative references be normative or vice-versa? See the [IESG
Statement on Normative and Informative References][16].
Each of IDR chairs have walked through Normative and Informative references.
[Pending - Asking for RTG-AD (John Scudder) to do early review on
normative/non-normative references. ]
Note: draft-ietf-idr-bgp-ct-27 references an informative reference:
BGP-CT-UPDATE-PACKING-TEST] which is a document on the IETF IDR WG Github.
Read access is allowed for all.
see:
https://raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/1a75d4d10d4df0f1fd7dcc041c2c868704b092c7/update-packing-test-results.txt
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 freely available and published RFCs.
See comment above regarding 1 informative reference at IETF IDR WG github.;
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?
There are no normative references that are not at RFC level.
Informative references are RFCs, drafts, or one github reference (see #15
above).
19. Will publication of this document change the status of any existing RFCs? No
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? not applicable. If not, explain why and point to the part of
the document where the relationship of this document to these other RFCs is
discussed.- not applicable.
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. yes,
confirmed
Confirm that any referenced IANA registries have been clearly identified.
Yes, confirmed. Confirm that each newly created IANA registry specifies its
initial contents, allocations procedures, and a reasonable name (see [RFC
8126][11]). yes, Confirmed.
[pending] Due to a complexity, an early request to review IANA allocation
has been sent.
New registries:
Transitive Transport Class Extended Community Sub-Types Registry
Non-Transitive Transport Class Extended Community Sub-Types Registry
BGP CT Parameters
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 IANA registries that require Designated Expert Review are listed in this
draft.
[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/