I-D list for Inter-Domain Routing RSS FeedDocument changesurn:uuid:28e630a2-f96f-5b3b-b23e-12c3e26ff8502024-03-28T18:25:40-0700BGP Extensions for Routing Policy Distribution (RPD)9834852024-03-28T16:38:03-07002024-03-28T16:38:03-0700(System)Request for posting confirmation emailed to previous authors: Gyan Mishra <gyan.s.mishra@verizon.com>, Haibo Wang <rainsword.wang@huawei.com>, Huaimo Chen <huaimo.chen@futurewei.com>, Liang Ou <ouliang@chinatelecom.cn>, Yujia Luo <luoyuj@sdu.edu.cn>, Zhenbin Li <lizhenbin@huawei.com>, idr-chairs@ietf.orgnew_submissionietfidrKeyur PatelJohn Scudderactivewatchingwg-docBGP Extensions for Routing Policy Distribution (RPD)9834842024-03-28T16:38:02-07002024-03-28T16:38:02-0700Huaimo ChenUploaded new revisionnew_submissionietfidrKeyur PatelJohn Scudderactivewatchingwg-docBGP CT - Adaptation to SRv6 dataplane9834062024-03-27T16:35:32-07002024-03-27T16:35:32-0700Nagendra NainarRequest for Early review by OPSDIR Completed: Has Issues. Reviewer: Nagendra Nainar. Sent review to list.closed_review_assignmentietfidrSusan HaresactiveidexistswriteupwDistribution of SR P2MP Policies and State using BGP-LS9830222024-03-22T04:42:52-07002024-03-22T04:42:52-0700Changwang LinNew version available: <b>draft-liu-idr-bgpls-sr-p2mp-policy-distribution-03.txt</b>new_revisionnoneactiveidexists This document specifies the extensions to BGP Link State (BGP-LS) to
distribute SR P2MP Policies and state. This allows operators to
establish a consistent view of the underlying multicast network
state, providing an efficient mechanism for the advertisement and
synchronization of SR P2MP policies.
03Distribution of SR P2MP Policies and State using BGP-LS9830212024-03-22T04:42:52-07002024-03-22T04:42:52-0700Changwang LinNew version accepted (logged-in submitter: Changwang Lin)new_submissionnoneactiveidexistsDistribution of SR P2MP Policies and State using BGP-LS9830202024-03-22T04:42:51-07002024-03-22T04:42:51-0700Changwang LinUploaded new revisionnew_submissionnoneactiveidexistsBGP CT - Adaptation to SRv6 dataplane9827402024-03-21T07:10:10-07002024-03-21T07:10:10-0700Carlos PignataroRequest for Early review by OPSDIR is assigned to Nagendra Nainarassigned_review_requestietfidrSusan HaresactiveidexistswriteupwBGP Color-Aware Routing (CAR)9827392024-03-21T07:10:09-07002024-03-21T07:10:09-0700Carlos PignataroRequest for Early review by OPSDIR is assigned to Yingzhen Quassigned_review_requestietfidrSusan HaresactiveidexistswriteupwAdvertisement of Segment Routing Policies using BGP Link-State9825662024-03-20T21:47:06-07002024-03-20T21:47:06-0700Ketan TalaulikarNew version available: <b>draft-ietf-idr-bgp-ls-sr-policy-04.txt</b>new_revisionietfidrSusan Haresactiveidexistswg-doc This document describes a mechanism to collect the Segment Routing
Policy information that is locally available in a node and advertise
it into BGP Link-State (BGP-LS) updates. Such information can be
used by external components for path computation, re-optimization,
service placement, network visualization, etc.
04Advertisement of Segment Routing Policies using BGP Link-State9825652024-03-20T21:47:05-07002024-03-20T21:47:05-0700Ketan TalaulikarNew version accepted (logged-in submitter: Ketan Talaulikar)new_submissionietfidrSusan Haresactiveidexistswg-docAdvertisement of Segment Routing Policies using BGP Link-State9825642024-03-20T21:47:04-07002024-03-20T21:47:04-0700Ketan TalaulikarUploaded new revisionnew_submissionietfidrSusan Haresactiveidexistswg-docBGP Extension for 5G Edge Service Metadata9824232024-03-20T17:09:17-07002024-03-20T17:09:17-0700Linda DunbarNew version available: <b>draft-ietf-idr-5g-edge-service-metadata-16.txt</b>new_revisionietfidractiveidexistswg-doc This draft describes a new Metadata Path Attribute and some Sub-TLVs
for egress routers to advertise the Metadata about the attached edge
services (ES). The edge service Metadata can be used by the ingress
routers in the 5G Local Data Network to make path selections not only
based on the routing cost but also the running environment of the
edge services. The goal is to improve latency and performance for 5G
edge services.
The extension enables an edge service at one specific location to be
more preferred than the others with the same IP address (ANYCAST) to
receive data flow from a specific source, like a specific User
Equipment (UE).
16BGP Extension for 5G Edge Service Metadata9824222024-03-20T17:09:16-07002024-03-20T17:09:16-0700Linda DunbarNew version accepted (logged-in submitter: Linda Dunbar)new_submissionietfidractiveidexistswg-docBGP Extension for 5G Edge Service Metadata9824212024-03-20T17:09:16-07002024-03-20T17:09:16-0700Linda DunbarUploaded new revisionnew_submissionietfidractiveidexistswg-docBGP Classful Transport Planes9823572024-03-20T13:58:25-07002024-03-20T13:58:25-0700Susan HaresRequested Early review by SECDIRrequested_reviewietfidrSusan HaresactiveidexistswriteupwBGP Classful Transport Planes9823562024-03-20T13:51:08-07002024-03-20T13:51:08-0700Susan Hares# Document Shepherd Write-Up for Group Documents<br>*This version is dated 4 July 2022. [see RFC4858 for details] <br><br>Need information: <br>3) link to Dhruv's review of CT drafts<br>4) Ask for SecDir review of -30 <br><br>## Document History<br><br>1. Does the working group (WG) consensus represent the strong concurrence of a<br> few individuals, with others being silent, or did it reach broad agreement?<br><br>The CT progression after adoption is tracked on both the IDR Wiki<br>and the IDR github repository: ietf-wg-idr/draft-ietf-idr-bgp-ct<br>https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues<br><br>Post 2nd WG LC Shepherd's review of -26.txt <br>https://mailarchive.ietf.org/arch/msg/idr/7PIQx2nE0Y4d-lR7bIpTPL_TMR0/<br><br>Summary of calls: (in reverse time order) <br>2nd WG LC: 2/16/2024 to 3/1/2024 <br>https://mailarchive.ietf.org/arch/msg/idr/Ud2coGDvdXYy7x-SHPSK2Onwjx4/<br>Status: Consensus on publication of draft-ietf-idr-bgp-ct and draft-ietf-idr-bgp-ct-srv6<br>https://mailarchive.ietf.org/arch/msg/idr/oNY5gAcE21y1bke6tBzeb76uVo4/<br>https://mailarchive.ietf.org/arch/msg/idr/rJC4O726QqUoDEqFTffOF9EvX_U/<br><br>----<br>1st WG LC: draft-ietf-idr-bgp-ct-09.txt (6/26/2023 to 7/17/2023<br>https://mailarchive.ietf.org/arch/msg/idr/KYZbOsg2y4jcOfjV31pee5uhMjQ/<br>extension to 7/28: https://mailarchive.ietf.org/arch/msg/idr/Qr8GhdlEi8viaZxOCaWii3cA51s/<br>Extension to 8/01: https://mailarchive.ietf.org/arch/msg/idr/fC--NIU7VlyOjmNJwIcsXhXFvSk/<br>status: No consensus reached<br><br>The shepherd's write-up on this topic is available on the IDR wiki<br>https://wiki.ietf.org/e/en/group/idr/CT-WGLC<br><br>Email message notifying the WG of 1 WG LC Shepherd's report: <br>https://mailarchive.ietf.org/arch/msg/idr/klBUhMe9AsdflYhIYVEhSIps_lg/<br>---------<br>Adoption call results: (as part of status) <br>https://mailarchive.ietf.org/arch/msg/idr/0V6pBTQyCmh3t3h9cMqxZ3N0s7Q/<br><br>Adoption call: Time: 7/6/2022 to 7/27/2022 in 3 mail threads.<br>Part 1 of CAR/CT Adoption call (7/6 to 7/27): Informational Questions<br>https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/<br><br>Part 2 of CAR/CT Adoption call (7/6 to 7/27): Adoption call<br>https://mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/<br><br>Part 3 of CAR/CT Adoption call (7/14 to 7/27) - Please note that Part 3 has a specific format for posting.<br>https://mailarchive.ietf.org/arch/msg/idr/fTFYwF54WRHcj7PDt2t7sOQg6vo/<br><br>This adoption call was preceded by the following:<br>Email Discussion before IETF-113<br>https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/<br><br>Note: The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022, <br>that for route resolution and route origination/propagation, <br>BGP-CAR and BGP-CT are functionally identical but operationally different.<br><br>Presentations from IETF-108 to IETF-113<br>IDR interim on January 24, 2022<br>(https://datatracker.ietf.org/meeting/interim-2022-idr-02/session/idr)<br><br><br>2. Was there controversy about particular points, or were there decisions where<br> the consensus was particularly rough?<br><br><br>Rough Adoption decision: <br>The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022, <br>that for route resolution and route origination/propagation, <br>BGP-CAR and BGP-CT are functionally identical but operationally different.<br><br>IDR WG could not come to a consensus on CAR vs. CT. IDR Chairs elected to adopt <br>both CAR and CT drafts as experimental drafts. Experience in the market <br>place will help determine which is better operationally. <br><br>Rough 1st WG LC of CAR/CT: The IDR WG LC for CAR and CT found the editors/authors/contributors<br>of CAR commenting on the CT draft (Just as CT authors commented on CAR draft).<br>In some ways, this lively debate helped find problems in the specifications. <br><br>2nd WG LC of CAR/CT: This WG LC did not have a lot of <br>CAR/CT editor discussions because the IDR Shepherding Chair had <br>a private discussion between editors prior to the 2nd WG LC. <br><br>During 2nd WG LC: Concern on Split of CT drafts into 3 drafts: <br>https://mailarchive.ietf.org/arch/msg/idr/29CYvVl0RnW0hJSU3il3p_cqt80/<br><br>Robert Raszuk raised a Concern regarding the splitting of the <br>CT draft into three parts (draft-ietf-idr-bgp-ct, draft-ietf-idr-bgp-ct-srv6, <br>and draft-ietf-idr-bgp-fwd-rr). Robert objected to the draft-ietf-idr-bgp-fwd-rr<br>being a WG draft. The IDR chairs felt the text was in draft-ietf-idr-bgp-ct <br>since version -09, so Robert's concerns about being surprised as<br>WG draft was not justified. However, it does point to the value of <br>the IDR chairs splitting this work out of the draft-ietf-idr-bgp-ct draft. <br><br>------<br>Dependencies on Spring: <br>a) Functional dependency - caused only theoretical scaling results <br>Due to a lack of adoption of the Spring Requirements document<br>draft-hr-spring-intentaware-routing-using-color-03, this WG <br>Shepherd allowed the scaling results to be theoretical without proof in CT. <br><br>b) Normative dependency on draft-ietf-idr-salih-spring-srv6-inter-domain-sids-04. <br>There is a normative dependency on an individual draft that is waiting for adoption. <br>The Spring chairs have been notified that IDR draft-ietf-idr-bgp-ct-srv6<br>has normative dependencies on draft-ietf-idr-salih-spring-srv6-inter-domain-sids. <br><br>Dependencies with PCE <br>Dhruv Dhody reviewed the interactions with PCE drafts. <br>He sent comments to the CT authors. CT authors updated their drafts with changes. <br><br>Dependencies with BESS: <br>BESS chairs were queried about reviewing the CAR and CT drafts. <br>No direct information was received. <br><br>-----<br>Alternatives for SRv6 without CAR or CT. <br>A third draft (draft-ietf-idr-cpr-00) was adopted as an informational draft. <br>This informational draft provides a way to encode intent for <br>SRv6 by operational practices rather than a new protocol. <br><br>## Directorate Reviews: (tracked by Datatracker) with comments from shepherd <br>RTG-DIR reviews: <br>Early Review of draft-ietf-idr-bgp-ct-09 (Med Boucadair)- status: has issues, excellent review<br>https://mailarchive.ietf.org/arch/msg/rtg-dir/aawFfvd29zERSBK4ydDDhxEQGRw<br>Early Review of draft-ietf-idr-bgp-ct-18 (Jonathan Hardwick) - status: has nits, good review <br>https://mailarchive.ietf.org/arch/msg/rtg-dir/FLGmC0-ufqPsZpH_LmgL2eWmWhY<br><br>OPS-DIR reviews: <br>Early Review of draft-ietf-idr-bgp-ct-12 (Bo Wu) - status: Has issues, Quality: good review, 4 issues mentioned <br>https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-12-opsdir-early-wu-2023-08-03/<br>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<br>https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-19-opsdir-early-wu-2024-01-05/<br><br>SEC-DIR Review: <br>comments from the WG chair on SEC-DIR early review: <br>Intent (Color) could have security issues in this draft. The service data (customer data)<br>is being tracked by intent and placed over service quality tunnels. <br>In one view, it is just more layering. In an alternate view, the color exposes some abstract qualities of the network. <br><br>Early review of draft-ietf-idr-bgp-ct-18 (by Magnus Nystrom)- status: has issues. <br>Issues stated: <br>1) Why does the definition of "new AFI/SAFI to pass routes" not change any underlying security characteristics? <br> This should be explained better.<br>2) Where is it stated in the document - "Mechanisms described in this document follow a "Walled Garden" approach? <br> This should be explained better. <br>3) It is stated that BGP origin validation "could" be used to "increase assurance" that information has not been falsified.<br> Firstly, "could" does not say much to an implementer. Is this intended to be "SHOULD"? <br> What's the risk of not using origin validation? <br> And conversely, what assurance is given if BGP origin validation is not used (the "increased assurance" part).<br>4) It is stated that: <br> "In order to mitigate the risk of the diversion of traffic from its<br> intended destination, [the] existing BGPsec solution could be extended, and<br> supported for this SAFI."<br> What does "could" mean here? <br>5) It is also stated that "as long as filtering [and other measures] are<br> applied diligently, "risk of [traffic diversion] is eliminated". <br> Is this really the case? That it is entirely eliminated?<br>6) Not being an expert in this area, I just want to call out the<br> following items that I ask the authors to ensure that they are covered:<br> 1. Is there anything in here which increases the risk of dDoS attacks?<br> 2. Do the mechanisms and constructs in this document introduce any<br> new risks related to unintended information disclosure?<br> 3. Do the mechanisms and constructs in this document introduce any<br> new risks due to spoofing of endpoint identities etc.?<br> 4. Do the mechanisms and constructs in this document introduce any<br> new risks due to modification of information exchanged, e.g., between AS<br> endpoints?<br> <br>Early review of draft-ietf-idr-bgp-ct-19 (by Magnus Nystrom)- status: has issues. Authors did not resolve -18 issues <br>https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-19-secdir-early-nystrom-2024-01-15/<br><br>Shepherd's note: Assigned github issue #69 to resolve before publication request sent to IESG. <br><br>TSV-Review: (due date 3/6/2024) - no response from review <br>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.<br><br>3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If<br> so, please summarize the areas of conflict in separate email messages to the<br> responsible Area Director. (It should be in a separate email because this<br> questionnaire is publicly available.)<br><br>Andrew mentioned he received feedback that there would be discomfort<br>if the CAR and CT do not progress to the Experimental simultaneously. <br>See Andrew Alston for additional details. <br><br>4. For protocol documents, are there existing implementations of the contents of<br> the document? Have a significant number of potential implementers indicated<br> plans to implement? Are any existing implementations reported somewhere,<br> either in the document itself (as [RFC 7942][3] recommends) or elsewhere<br> (where)?<br><br> Implementation report: <br> https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-bgp-ct<br> <br> Implementation of CT: Juniper, Freertg<br> Implementation of CT-srv6: (TBD) <br><br>5. Do the contents of this document closely interact with technologies in other<br> IETF working groups or external organizations, and would it therefore benefit<br> from their review? Have those reviews occurred? If yes, describe which<br> reviews took place.<br><br> Reviews requested from PCE, Spring, and BESS before 2nd WG LC. <br> Received reviews from PCE: [need link] <br> Received feedback from Spring chairs (Alvaro Retana)<br> The following drafts were in the option queue: <br> draft-hr-spring-intentaware-routing-using-color<br> draft-salih-spring-srv6-inter-domain-sids-04 (ct-srv6) <br> <br> Nothing was received from BESS. <br> RTG-DIR reviews: 2 early reviews - (-18) "has nits" <br> OPS-DIR reviews: 2 early reviews - (-19) "has nits" <br> SEC-DIR reviews: 2 early reviews - (-19) 6 problems + 4 questions (must be resolved) <br> TSV-DIR review: 1 early review requested - no response. <br> IANA Early review: IANA early review of draft-ietf-idr-bgp-ct-27 IANA section. <br> <br>6. Describe how the document meets any required formal expert review criteria,<br> such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.<br><br> No requirement for formal review (MIB, Yang, Media type, and URI)<br> A yang module for CT will be added to the list of Yang modules to create for BGP. <br><br>7. If the document contains a YANG module, has the final version of the module<br> been checked with any of the [recommended validation tools][4] for syntax and<br> formatting validation? If there are any resulting errors or warnings, what is<br> the justification for not fixing them at this time? Does the YANG module<br> comply with the Network Management Datastore Architecture (NMDA) as specified<br> in [RFC 8342][5]?<br><br> No Yang in the document<br><br>8. Describe reviews and automated checks performed to validate sections of the<br> final version of the document written in a formal language, such as XML code,<br> BNF rules, MIB definitions, CBOR's CDDL, etc.<br><br> No automated checking<br><br>## Document Shepherd Checks<br><br>9. Based on the shepherd's review of the document, is it their opinion that this<br> document is needed, clearly written, complete, correctly designed, and ready<br> to be handed off to the responsible Area Director?<br><br>Checks completed: <br> 1) Pre-Adoption by Jeff Haas and discussion among chairs <br> 2) Careful Adoption review resulted in a list of issues that needed to be resolved:<br> (https://wiki.ietf.org/group/idr/CAR-CTAdoption) <br> 3) Adoption call issues added to github for draft-ietf-idr-bgp-ct-27 <br> (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)<br> 4) 1st WG LC - <br> Prior to 1st WG LC: Shepherd verified that issues were addressed <br> and early Early Directorate reviews requested, <br> 1st WG LC: Shepherd report written <br> (see https://wiki.ietf.org/group/idr/CT-WGLC and <br> https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues) <br> Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas. <br> <br> 5) 2nd WG LC <br> Prior to 2nd WG LC: <br> a) Shepherd verified that issues raised in 1st WG LC were addressed.<br> b) Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas. <br> c) IDR Chair team resolutions were made - via email and meetings of <br> technical issues. <br> d) Early reviews requested (RTG-DIR, OPS-DIR, SEC-DIR, and TSV-DIR)<br> open reviews: resolution of SEC-DIR and lack of TSV-DIR <br> d) Meeting with CAR and CT editor teams during 2nd WGLC<br> e) two interims in 2024 - January 29 and February 26 - review status<br> 6) Post WG LC <br> a) Shepherd reports with editorial nits [resolved]<br> b) Shepherd report loaded into github as issues [Resolved]<br> c) Review issues with document editors before -27 submission [Resolved] <br> b) IANA review of -27 requested. [pending] <br> c) github issue loaded with Security Directorate review comments <br><br> 7) Current waiting status: <br> a) Response from IANA review of -27 <br> b) Response from SEC-DIR resolution check <br> c) final NITS check <br><br>10. Several IETF Areas have assembled [lists of common issues that their<br> reviewers encounter][6]. <br> For which areas have such issues been identified<br> and addressed? See Early Review comments.<br> <br> For which does this still need to happen in subsequent reviews? <br> <br> 3/12/2024 status: Pending resolution: <br> SEC-DIR Early review resolution - check text + SEC-DIR Reviewer<br> (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69) <br> Pending reviews: TSV Early Review, IANA early review, IETF-119 RTG-AD discussion <br><br>11. What type of RFC publication is being requested on the IETF stream ([Best<br> Current Practice][12], [Proposed Standard, Internet Standard][13],<br> [Informational, Experimental or Historic][14])? Why is this the proper type<br> of RFC? Do all Datatracker state attributes correctly reflect this intent?<br><br> Experimental draft. Why? IDR cannot settle on a single solution for Intent-based (Color) routing. <br> The top 2 solutions are forwarded as experimental drafts to allow operational deployment to give feedback.<br><br> Do all Datatracker state attributes correctly reflect this intent? Yes . <br> <br>12. Have reasonable efforts been made to remind all authors of the intellectual<br> property rights (IPR) disclosure obligations described in [BCP 79][7]? To<br> the best of your knowledge, have all required disclosures been filed? If<br> not, explain why. If yes, summarize any relevant discussion, including links<br> to publicly-available messages when applicable.<br><br>Editors:<br>2nd WG LC -03 <br>Kaliraj Vairavakkali (kaliraj@juniper.net) <br>https://mailarchive.ietf.org/arch/msg/idr/ZL7tOk3fgqeIRM5dfKfx_GbIh2w/<br><br>Natrajan Venkataraman (natv@juniper.net) <br>https://mailarchive.ietf.org/arch/msg/idr/eh3IdjyMjJVQSwOx2CD95iKg1-4/<br><br>CoAuthors: <br>Reshma Das (dreshma@juniper.net) <br>https://mailarchive.ietf.org/arch/msg/idr/Ei8WY3sVYAhnECr1w40Y8C5zQ-Y/<br><br>Israel Means (israel.means@att.com) <br>https://mailarchive.ietf.org/arch/msg/idr/iniOhZ1BknkBhe2l8DYL5aL_lGk/<br><br>Csaba Mates (ietf@nop.hu)<br>https://mailarchive.ietf.org/arch/msg/idr/NSxyfq98238jOIllMgIrBF54aeg/<br><br>Deepak J. Gowda (dgowda@extremenetworks.com) [2nd WG LC] <br>https://mailarchive.ietf.org/arch/msg/idr/FWf7jsy7mFJDiW3stAWeJ_DU0oU/<br><br>Contributors: <br>Balaji Rajagoplan (balajir@juniper.net) <br>https://mailarchive.ietf.org/arch/msg/idr/SfJQVDClw7y8vXYoG8wlLKRgyLQ/<br><br><br>Rajesh M (mrajesh@juniper.net) <br>https://mailarchive.ietf.org/arch/msg/idr/4T2BDGnaZUmtWUPjFVIOAFL-ZoI/<br><br>Chaitanya Yadlapalli (cy098d@att.com) <br>https://mailarchive.ietf.org/arch/msg/idr/M1c3trnvMiVn3_QQU9FqbkuvHA0/<br><br>Mazen Khaddam (mazen.khaddam@cox.com) <br>https://mailarchive.ietf.org/arch/msg/idr/lhBotT08JzICX-uPUfhMUSA7uzc/<br><br>Rafal Jan Szarecki (Google) <br>https://mailarchive.ietf.org/arch/msg/idr/r09fylzRRgssJqDoQnhy66qCr-g/<br><br>Xiaohu Xu (Captialonline) [from 1st WG LC] <br>https://mailarchive.ietf.org/arch/msg/idr/DBuobWpmj_ce0IOUWDTZU7m095E/<br>2nd WG LC<br>https://mailarchive.ietf.org/arch/msg/idr/Uh39xPb20FTsmORAjgRlce8bwfc/<br><br>Contributor for [-12] missing in [-27]<br>Gyan Mishra (gyan.s.mishra@verizon.com) - dropped as of [-11] <br>before 1st WG LC. Missing IPR statement. <br><br>13. Has each author, editor, and contributor shown their willingness to be<br> listed as such? If the total number of authors and editors on the front page<br> is greater than five, please provide a justification.<br><br>2 editors on front page. <br>All IPR statements good for -27 except for Xiahou Xu. <br>issue with Gyan Mishra - no longer contributor after -11<br><br>14. Document any remaining I-D nits in this document. Simply running the [idnits<br> tool][8] is not enough; please review the ["Content Guidelines" on<br> authors.ietf.org][15]. (Also note that the current idnits tool generates<br> some incorrect warnings; a rewrite is underway.)<br><br>[pending] NITS - see github reference <br>(see https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/70) <br> - 2 lines over 72 length, but it seems the tools. <br><br>-(2477): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding<br>-(2501): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding<br><br>15. Should any informative references be normative or vice-versa? See the [IESG<br> Statement on Normative and Informative References][16].<br> <br> Each of IDR chairs have walked through Normative and Informative references. <br> [Pending - Asking for RTG-AD (John Scudder) to do early review on <br> normative/non-normative references. ] <br><br> Note: draft-ietf-idr-bgp-ct-27 references an informative reference: <br> BGP-CT-UPDATE-PACKING-TEST] which is a document on the IETF IDR WG Github. <br> Read access is allowed for all. <br> see: https://raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/1a75d4d10d4df0f1fd7dcc041c2c868704b092c7/update-packing-test-results.txt<br><br>16. List any normative references that are not freely available to anyone. <br> Did the community have sufficient access to review any such normative<br> references?<br><br> All normative references are freely available and published RFCs. <br> See comment above regarding 1 informative reference at IETF IDR WG github.; <br><br>17. Are there any normative downward references (see [RFC 3967][9] and [BCP<br> 97][10]) that are not already listed in the [DOWNREF registry][17]? If so,<br> list them.<br> <br> No. <br><br>18. Are there normative references to documents that are not ready to be<br> submitted to the IESG for publication or are otherwise in an unclear state?<br> If so, what is the plan for their completion?<br><br> There are no normative references that are not at RFC level. <br> Informative references are RFCs, drafts, or one github reference (see #15 above). <br><br>19. Will publication of this document change the status of any existing RFCs? No <br> If so, does the Datatracker metadata correctly reflect this and are those RFCs<br> listed on the title page, in the abstract, and discussed in the<br> introduction? not applicable. <br> If not, explain why and point to the part of the document<br> where the relationship of this document to these other RFCs is discussed.- not applicable. <br><br>20. Describe the document shepherd's review of the IANA considerations section,<br> especially with regard to its consistency with the body of the document.<br><br> Confirm that all aspects of the document requiring IANA assignments are<br> associated with the appropriate reservations in IANA registries. yes, confirmed <br><br> Confirm that any referenced IANA registries have been clearly identified. Yes, confirmed. <br> Confirm that each newly created IANA registry specifies its initial contents,<br> allocations procedures, and a reasonable name (see [RFC 8126][11]). yes, Confirmed. <br><br> [pending] Due to a complexity, an early request to review IANA allocation has <br> been sent. <br><br> New registries: <br> Transitive Transport Class Extended Community Sub-Types Registry<br> Non-Transitive Transport Class Extended Community Sub-Types Registry<br> BGP CT Parameters<br><br>21. List any new IANA registries that require Designated Expert Review for<br> future allocations. Are the instructions to the Designated Expert clear?<br> Please include suggestions of designated experts, if appropriate.<br><br> No IANA registries that require Designated Expert Review are listed in this draft. <br><br>[1]: https://www.ietf.org/about/groups/iesg/<br>[2]: https://www.rfc-editor.org/rfc/rfc4858.html<br>[3]: https://www.rfc-editor.org/rfc/rfc7942.html<br>[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools<br>[5]: https://www.rfc-editor.org/rfc/rfc8342.html<br>[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics<br>[7]: https://www.rfc-editor.org/info/bcp79<br>[8]: https://www.ietf.org/tools/idnits/<br>[9]: https://www.rfc-editor.org/rfc/rfc3967.html<br>[10]: https://www.rfc-editor.org/info/bcp97<br>[11]: https://www.rfc-editor.org/rfc/rfc8126.html<br>[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5<br>[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1<br>[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2<br>[15]: https://authors.ietf.org/en/content-guidelines-overview<br>[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/<br>[17]: https://datatracker.ietf.org/doc/downref/<br><br>changed_protocol_writeupietfidrSusan HaresactiveidexistswriteupwBGP Classful Transport Planes9823332024-03-20T13:14:42-07002024-03-20T13:14:42-0700Susan Hares# Document Shepherd Write-Up for Group Documents<br>*This version is dated 4 July 2022. [see RFC4858 for details] <br><br>Need information: <br>3) link to Dhruv's review of CT drafts<br>4) Resolve SEC-DIR issues (github issue 69) <br>5) Pending Early Directorate reviews: IANA (github issue 63) and TSV-DIR review <br>6) Check on nits issues (github issue 70) <br><br><br>## Document History<br><br>1. Does the working group (WG) consensus represent the strong concurrence of a<br> few individuals, with others being silent, or did it reach broad agreement?<br><br>The CT progression after adoption is tracked on both the IDR Wiki<br>and the IDR github repository: ietf-wg-idr/draft-ietf-idr-bgp-ct<br>https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues<br><br>Post 2nd WG LC Shepherd's review of -26.txt <br>https://mailarchive.ietf.org/arch/msg/idr/7PIQx2nE0Y4d-lR7bIpTPL_TMR0/<br><br>Summary of calls: (in reverse time order) <br>2nd WG LC: 2/16/2024 to 3/1/2024 <br>https://mailarchive.ietf.org/arch/msg/idr/Ud2coGDvdXYy7x-SHPSK2Onwjx4/<br>Status: Consensus on publication of draft-ietf-idr-bgp-ct and draft-ietf-idr-bgp-ct-srv6<br>https://mailarchive.ietf.org/arch/msg/idr/oNY5gAcE21y1bke6tBzeb76uVo4/<br>https://mailarchive.ietf.org/arch/msg/idr/rJC4O726QqUoDEqFTffOF9EvX_U/<br><br>----<br>1st WG LC: draft-ietf-idr-bgp-ct-09.txt (6/26/2023 to 7/17/2023<br>https://mailarchive.ietf.org/arch/msg/idr/KYZbOsg2y4jcOfjV31pee5uhMjQ/<br>extension to 7/28: https://mailarchive.ietf.org/arch/msg/idr/Qr8GhdlEi8viaZxOCaWii3cA51s/<br>Extension to 8/01: https://mailarchive.ietf.org/arch/msg/idr/fC--NIU7VlyOjmNJwIcsXhXFvSk/<br>status: No consensus reached<br><br>The shepherd's write-up on this topic is available on the IDR wiki<br>https://wiki.ietf.org/e/en/group/idr/CT-WGLC<br><br>Email message notifying the WG of 1 WG LC Shepherd's report: <br>https://mailarchive.ietf.org/arch/msg/idr/klBUhMe9AsdflYhIYVEhSIps_lg/<br>---------<br>Adoption call results: (as part of status) <br>https://mailarchive.ietf.org/arch/msg/idr/0V6pBTQyCmh3t3h9cMqxZ3N0s7Q/<br><br>Adoption call: Time: 7/6/2022 to 7/27/2022 in 3 mail threads.<br>Part 1 of CAR/CT Adoption call (7/6 to 7/27): Informational Questions<br>https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/<br><br>Part 2 of CAR/CT Adoption call (7/6 to 7/27): Adoption call<br>https://mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/<br><br>Part 3 of CAR/CT Adoption call (7/14 to 7/27) - Please note that Part 3 has a specific format for posting.<br>https://mailarchive.ietf.org/arch/msg/idr/fTFYwF54WRHcj7PDt2t7sOQg6vo/<br><br>This adoption call was preceded by the following:<br>Email Discussion before IETF-113<br>https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/<br><br>Note: The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022, <br>that for route resolution and route origination/propagation, <br>BGP-CAR and BGP-CT are functionally identical but operationally different.<br><br>Presentations from IETF-108 to IETF-113<br>IDR interim on January 24, 2022<br>(https://datatracker.ietf.org/meeting/interim-2022-idr-02/session/idr)<br><br><br>2. Was there controversy about particular points, or were there decisions where<br> the consensus was particularly rough?<br><br><br>Rough Adoption decision: <br>The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March 21, 2022, <br>that for route resolution and route origination/propagation, <br>BGP-CAR and BGP-CT are functionally identical but operationally different.<br><br>IDR WG could not come to a consensus on CAR vs. CT. IDR Chairs elected to adopt <br>both CAR and CT drafts as experimental drafts. Experience in the market <br>place will help determine which is better operationally. <br><br>Rough 1st WG LC of CAR/CT: The IDR WG LC for CAR and CT found the editors/authors/contributors<br>of CAR commenting on the CT draft (Just as CT authors commented on CAR draft).<br>In some ways, this lively debate helped find problems in the specifications. <br><br>2nd WG LC of CAR/CT: This WG LC did not have a lot of <br>CAR/CT editor discussions because the IDR Shepherding Chair had <br>a private discussion between editors prior to the 2nd WG LC. <br><br>During 2nd WG LC: Concern on Split of CT drafts into 3 drafts: <br>https://mailarchive.ietf.org/arch/msg/idr/29CYvVl0RnW0hJSU3il3p_cqt80/<br><br>Robert Raszuk raised a Concern regarding the splitting of the <br>CT draft into three parts (draft-ietf-idr-bgp-ct, draft-ietf-idr-bgp-ct-srv6, <br>and draft-ietf-idr-bgp-fwd-rr). Robert objected to the draft-ietf-idr-bgp-fwd-rr<br>being a WG draft. The IDR chairs felt the text was in draft-ietf-idr-bgp-ct <br>since version -09, so Robert's concerns about being surprised as<br>WG draft was not justified. However, it does point to the value of <br>the IDR chairs splitting this work out of the draft-ietf-idr-bgp-ct draft. <br><br>------<br>Dependencies on Spring: <br>a) Functional dependency - caused only theoretical scaling results <br>Due to a lack of adoption of the Spring Requirements document<br>draft-hr-spring-intentaware-routing-using-color-03, this WG <br>Shepherd allowed the scaling results to be theoretical without proof in CT. <br><br>b) Normative dependency on draft-ietf-idr-salih-spring-srv6-inter-domain-sids-04. <br>There is a normative dependency on an individual draft that is waiting for adoption. <br>The Spring chairs have been notified that IDR draft-ietf-idr-bgp-ct-srv6<br>has normative dependencies on draft-ietf-idr-salih-spring-srv6-inter-domain-sids. <br><br>Dependencies with PCE <br>Dhruv Dhody reviewed the interactions with PCE drafts. <br>He sent comments to the CT authors. CT authors updated their drafts with changes. <br><br>Dependencies with BESS: <br>BESS chairs were queried about reviewing the CAR and CT drafts. <br>No direct information was received. <br><br>-----<br>Alternatives for SRv6 without CAR or CT. <br>A third draft (draft-ietf-idr-cpr-00) was adopted as an informational draft. <br>This informational draft provides a way to encode intent for <br>SRv6 by operational practices rather than a new protocol. <br><br>## Directorate Reviews: (tracked by Datatracker) with comments from shepherd <br>RTG-DIR reviews: <br>Early Review of draft-ietf-idr-bgp-ct-09 (Med Boucadair)- status: has issues, excellent review<br>https://mailarchive.ietf.org/arch/msg/rtg-dir/aawFfvd29zERSBK4ydDDhxEQGRw<br>Early Review of draft-ietf-idr-bgp-ct-18 (Jonathan Hardwick) - status: has nits, good review <br>https://mailarchive.ietf.org/arch/msg/rtg-dir/FLGmC0-ufqPsZpH_LmgL2eWmWhY<br><br>OPS-DIR reviews: <br>Early Review of draft-ietf-idr-bgp-ct-12 (Bo Wu) - status: Has issues, Quality: good review, 4 issues mentioned <br>https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-12-opsdir-early-wu-2023-08-03/<br>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<br>https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-19-opsdir-early-wu-2024-01-05/<br><br>SEC-DIR Review: <br>comments from the WG chair on SEC-DIR early review: <br>Intent (Color) could have security issues in this draft. The service data (customer data)<br>is being tracked by intent and placed over service quality tunnels. <br>In one view, it is just more layering. In an alternate view, the color exposes some abstract qualities of the network. <br><br>Early review of draft-ietf-idr-bgp-ct-18 (by Magnus Nystrom)- status: has issues. <br>Issues stated: <br>1) Why does the definition of "new AFI/SAFI to pass routes" not change any underlying security characteristics? <br> This should be explained better.<br>2) Where is it stated in the document - "Mechanisms described in this document follow a "Walled Garden" approach? <br> This should be explained better. <br>3) It is stated that BGP origin validation "could" be used to "increase assurance" that information has not been falsified.<br> Firstly, "could" does not say much to an implementer. Is this intended to be "SHOULD"? <br> What's the risk of not using origin validation? <br> And conversely, what assurance is given if BGP origin validation is not used (the "increased assurance" part).<br>4) It is stated that: <br> "In order to mitigate the risk of the diversion of traffic from its<br> intended destination, [the] existing BGPsec solution could be extended, and<br> supported for this SAFI."<br> What does "could" mean here? <br>5) It is also stated that "as long as filtering [and other measures] are<br> applied diligently, "risk of [traffic diversion] is eliminated". <br> Is this really the case? That it is entirely eliminated?<br>6) Not being an expert in this area, I just want to call out the<br> following items that I ask the authors to ensure that they are covered:<br> 1. Is there anything in here which increases the risk of dDoS attacks?<br> 2. Do the mechanisms and constructs in this document introduce any<br> new risks related to unintended information disclosure?<br> 3. Do the mechanisms and constructs in this document introduce any<br> new risks due to spoofing of endpoint identities etc.?<br> 4. Do the mechanisms and constructs in this document introduce any<br> new risks due to modification of information exchanged, e.g., between AS<br> endpoints?<br> <br>Early review of draft-ietf-idr-bgp-ct-19 (by Magnus Nystrom)- status: has issues. Authors did not resolve -18 issues <br>https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-19-secdir-early-nystrom-2024-01-15/<br><br>Shepherd's note: Assigned github issue #69 to resolve before publication request sent to IESG. <br><br>TSV-Review: (due date 3/6/2024) - no response from review <br>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.<br><br>3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If<br> so, please summarize the areas of conflict in separate email messages to the<br> responsible Area Director. (It should be in a separate email because this<br> questionnaire is publicly available.)<br><br>Andrew mentioned he received feedback that there would be discomfort<br>if the CAR and CT do not progress to the Experimental simultaneously. <br>See Andrew Alston for additional details. <br><br>4. For protocol documents, are there existing implementations of the contents of<br> the document? Have a significant number of potential implementers indicated<br> plans to implement? Are any existing implementations reported somewhere,<br> either in the document itself (as [RFC 7942][3] recommends) or elsewhere<br> (where)?<br><br> Implementation report: <br> https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-bgp-ct<br> <br> Implementation of CT: Juniper, Freertg<br> Implementation of CT-srv6: (TBD) <br><br>5. Do the contents of this document closely interact with technologies in other<br> IETF working groups or external organizations, and would it therefore benefit<br> from their review? Have those reviews occurred? If yes, describe which<br> reviews took place.<br><br> Reviews requested from PCE, Spring, and BESS before 2nd WG LC. <br> Received reviews from PCE: [need link] <br> Received feedback from Spring chairs (Alvaro Retana)<br> The following drafts were in the option queue: <br> draft-hr-spring-intentaware-routing-using-color<br> draft-salih-spring-srv6-inter-domain-sids-04 (ct-srv6) <br> <br> Nothing was received from BESS. <br> RTG-DIR reviews: 2 early reviews - (-18) "has nits" <br> OPS-DIR reviews: 2 early reviews - (-19) "has nits" <br> SEC-DIR reviews: 2 early reviews - (-19) 6 problems + 4 questions (must be resolved) <br> TSV-DIR review: 1 early review requested - no response. <br> IANA Early review: IANA early review of draft-ietf-idr-bgp-ct-27 IANA section. <br> <br>6. Describe how the document meets any required formal expert review criteria,<br> such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.<br><br> No requirement for formal review (MIB, Yang, Media type, and URI)<br> A yang module for CT will be added to the list of Yang modules to create for BGP. <br><br>7. If the document contains a YANG module, has the final version of the module<br> been checked with any of the [recommended validation tools][4] for syntax and<br> formatting validation? If there are any resulting errors or warnings, what is<br> the justification for not fixing them at this time? Does the YANG module<br> comply with the Network Management Datastore Architecture (NMDA) as specified<br> in [RFC 8342][5]?<br><br> No Yang in the document<br><br>8. Describe reviews and automated checks performed to validate sections of the<br> final version of the document written in a formal language, such as XML code,<br> BNF rules, MIB definitions, CBOR's CDDL, etc.<br><br> No automated checking<br><br>## Document Shepherd Checks<br><br>9. Based on the shepherd's review of the document, is it their opinion that this<br> document is needed, clearly written, complete, correctly designed, and ready<br> to be handed off to the responsible Area Director?<br><br>Checks completed: <br> 1) Pre-Adoption by Jeff Haas and discussion among chairs <br> 2) Careful Adoption review resulted in a list of issues that needed to be resolved:<br> (https://wiki.ietf.org/group/idr/CAR-CTAdoption) <br> 3) Adoption call issues added to github for draft-ietf-idr-bgp-ct-27 <br> (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues)<br> 4) 1st WG LC - <br> Prior to 1st WG LC: Shepherd verified that issues were addressed <br> and early Early Directorate reviews requested, <br> 1st WG LC: Shepherd report written <br> (see https://wiki.ietf.org/group/idr/CT-WGLC and <br> https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues) <br> Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas. <br> <br> 5) 2nd WG LC <br> Prior to 2nd WG LC: <br> a) Shepherd verified that issues raised in 1st WG LC were addressed.<br> b) Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas. <br> c) IDR Chair team resolutions were made - via email and meetings of <br> technical issues. <br> d) Early reviews requested (RTG-DIR, OPS-DIR, SEC-DIR, and TSV-DIR)<br> open reviews: resolution of SEC-DIR and lack of TSV-DIR <br> d) Meeting with CAR and CT editor teams during 2nd WGLC<br> e) two interims in 2024 - January 29 and February 26 - review status<br> 6) Post WG LC <br> a) Shepherd reports with editorial nits [resolved]<br> b) Shepherd report loaded into github as issues [Resolved]<br> c) Review issues with document editors before -27 submission [Resolved] <br> b) IANA review of -27 requested. [pending] <br> c) github issue loaded with Security Directorate review comments <br><br> 7) Current waiting status: <br> a) Response from IANA review of -27 <br> b) Response from SEC-DIR resolution check <br> c) final NITS check <br><br>10. Several IETF Areas have assembled [lists of common issues that their<br> reviewers encounter][6]. <br> For which areas have such issues been identified<br> and addressed? See Early Review comments.<br> <br> For which does this still need to happen in subsequent reviews? <br> <br> 3/12/2024 status: Pending resolution: <br> SEC-DIR Early review resolution - check text + SEC-DIR Reviewer<br> (https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/69) <br> Pending reviews: TSV Early Review, IANA early review, IETF-119 RTG-AD discussion <br><br>11. What type of RFC publication is being requested on the IETF stream ([Best<br> Current Practice][12], [Proposed Standard, Internet Standard][13],<br> [Informational, Experimental or Historic][14])? Why is this the proper type<br> of RFC? Do all Datatracker state attributes correctly reflect this intent?<br><br> Experimental draft. Why? IDR cannot settle on a single solution for Intent-based (Color) routing. <br> The top 2 solutions are forwarded as experimental drafts to allow operational deployment to give feedback.<br><br> Do all Datatracker state attributes correctly reflect this intent? Yes . <br> <br>12. Have reasonable efforts been made to remind all authors of the intellectual<br> property rights (IPR) disclosure obligations described in [BCP 79][7]? To<br> the best of your knowledge, have all required disclosures been filed? If<br> not, explain why. If yes, summarize any relevant discussion, including links<br> to publicly-available messages when applicable.<br><br>Editors:<br>2nd WG LC -03 <br>Kaliraj Vairavakkali (kaliraj@juniper.net) <br>https://mailarchive.ietf.org/arch/msg/idr/ZL7tOk3fgqeIRM5dfKfx_GbIh2w/<br><br>Natrajan Venkataraman (natv@juniper.net) <br>https://mailarchive.ietf.org/arch/msg/idr/eh3IdjyMjJVQSwOx2CD95iKg1-4/<br><br>CoAuthors: <br>Reshma Das (dreshma@juniper.net) <br>https://mailarchive.ietf.org/arch/msg/idr/Ei8WY3sVYAhnECr1w40Y8C5zQ-Y/<br><br>Israel Means (israel.means@att.com) <br>https://mailarchive.ietf.org/arch/msg/idr/iniOhZ1BknkBhe2l8DYL5aL_lGk/<br><br>Csaba Mates (ietf@nop.hu)<br>https://mailarchive.ietf.org/arch/msg/idr/NSxyfq98238jOIllMgIrBF54aeg/<br><br>Deepak J. Gowda (dgowda@extremenetworks.com) [2nd WG LC] <br>https://mailarchive.ietf.org/arch/msg/idr/FWf7jsy7mFJDiW3stAWeJ_DU0oU/<br><br>Contributors: <br>Balaji Rajagoplan (balajir@juniper.net) <br>https://mailarchive.ietf.org/arch/msg/idr/SfJQVDClw7y8vXYoG8wlLKRgyLQ/<br><br><br>Rajesh M (mrajesh@juniper.net) <br>https://mailarchive.ietf.org/arch/msg/idr/4T2BDGnaZUmtWUPjFVIOAFL-ZoI/<br><br>Chaitanya Yadlapalli (cy098d@att.com) <br>https://mailarchive.ietf.org/arch/msg/idr/M1c3trnvMiVn3_QQU9FqbkuvHA0/<br><br>Mazen Khaddam (mazen.khaddam@cox.com) <br>https://mailarchive.ietf.org/arch/msg/idr/lhBotT08JzICX-uPUfhMUSA7uzc/<br><br>Rafal Jan Szarecki (Google) <br>https://mailarchive.ietf.org/arch/msg/idr/r09fylzRRgssJqDoQnhy66qCr-g/<br><br>Xiaohu Xu (Captialonline) [from 1st WG LC] <br>https://mailarchive.ietf.org/arch/msg/idr/DBuobWpmj_ce0IOUWDTZU7m095E/<br>2nd WG LC<br>https://mailarchive.ietf.org/arch/msg/idr/Uh39xPb20FTsmORAjgRlce8bwfc/<br><br>Contributor for [-12] missing in [-27]<br>Gyan Mishra (gyan.s.mishra@verizon.com) - dropped as of [-11] <br>before 1st WG LC. Missing IPR statement. <br><br>13. Has each author, editor, and contributor shown their willingness to be<br> listed as such? If the total number of authors and editors on the front page<br> is greater than five, please provide a justification.<br><br>2 editors on front page. <br>All IPR statements good for -27 except for Xiahou Xu. <br>issue with Gyan Mishra - no longer contributor after -11<br><br>14. Document any remaining I-D nits in this document. Simply running the [idnits<br> tool][8] is not enough; please review the ["Content Guidelines" on<br> authors.ietf.org][15]. (Also note that the current idnits tool generates<br> some incorrect warnings; a rewrite is underway.)<br><br>[pending] NITS - see github reference <br>(see https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/70) <br> - 2 lines over 72 length, but it seems the tools. <br><br>-(2477): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding<br>-(2501): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding<br><br>15. Should any informative references be normative or vice-versa? See the [IESG<br> Statement on Normative and Informative References][16].<br> <br> Each of IDR chairs have walked through Normative and Informative references. <br> [Pending - Asking for RTG-AD (John Scudder) to do early review on <br> normative/non-normative references. ] <br><br> Note: draft-ietf-idr-bgp-ct-27 references an informative reference: <br> BGP-CT-UPDATE-PACKING-TEST] which is a document on the IETF IDR WG Github. <br> Read access is allowed for all. <br> see: https://raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/1a75d4d10d4df0f1fd7dcc041c2c868704b092c7/update-packing-test-results.txt<br><br>16. List any normative references that are not freely available to anyone. <br> Did the community have sufficient access to review any such normative<br> references?<br><br> All normative references are freely available and published RFCs. <br> See comment above regarding 1 informative reference at IETF IDR WG github.; <br><br>17. Are there any normative downward references (see [RFC 3967][9] and [BCP<br> 97][10]) that are not already listed in the [DOWNREF registry][17]? If so,<br> list them.<br> <br> No. <br><br>18. Are there normative references to documents that are not ready to be<br> submitted to the IESG for publication or are otherwise in an unclear state?<br> If so, what is the plan for their completion?<br><br> There are no normative references that are not at RFC level. <br> Informative references are RFCs, drafts, or one github reference (see #15 above). <br><br>19. Will publication of this document change the status of any existing RFCs? No <br> If so, does the Datatracker metadata correctly reflect this and are those RFCs<br> listed on the title page, in the abstract, and discussed in the<br> introduction? not applicable. <br> If not, explain why and point to the part of the document<br> where the relationship of this document to these other RFCs is discussed.- not applicable. <br><br>20. Describe the document shepherd's review of the IANA considerations section,<br> especially with regard to its consistency with the body of the document.<br><br> Confirm that all aspects of the document requiring IANA assignments are<br> associated with the appropriate reservations in IANA registries. yes, confirmed <br><br> Confirm that any referenced IANA registries have been clearly identified. Yes, confirmed. <br> Confirm that each newly created IANA registry specifies its initial contents,<br> allocations procedures, and a reasonable name (see [RFC 8126][11]). yes, Confirmed. <br><br> [pending] Due to a complexity, an early request to review IANA allocation has <br> been sent. <br><br> New registries: <br> Transitive Transport Class Extended Community Sub-Types Registry<br> Non-Transitive Transport Class Extended Community Sub-Types Registry<br> BGP CT Parameters<br><br>21. List any new IANA registries that require Designated Expert Review for<br> future allocations. Are the instructions to the Designated Expert clear?<br> Please include suggestions of designated experts, if appropriate.<br><br> No IANA registries that require Designated Expert Review are listed in this draft. <br><br>[1]: https://www.ietf.org/about/groups/iesg/<br>[2]: https://www.rfc-editor.org/rfc/rfc4858.html<br>[3]: https://www.rfc-editor.org/rfc/rfc7942.html<br>[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools<br>[5]: https://www.rfc-editor.org/rfc/rfc8342.html<br>[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics<br>[7]: https://www.rfc-editor.org/info/bcp79<br>[8]: https://www.ietf.org/tools/idnits/<br>[9]: https://www.rfc-editor.org/rfc/rfc3967.html<br>[10]: https://www.rfc-editor.org/info/bcp97<br>[11]: https://www.rfc-editor.org/rfc/rfc8126.html<br>[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5<br>[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1<br>[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2<br>[15]: https://authors.ietf.org/en/content-guidelines-overview<br>[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/<br>[17]: https://datatracker.ietf.org/doc/downref/<br><br>changed_protocol_writeupietfidrSusan HaresactiveidexistswriteupwTraffic Steering using BGP FlowSpec with SR Policy9821312024-03-20T00:48:27-07002024-03-20T00:48:27-0700Cindy MorganShepherding AD changed to John Scudderadded_commentietfidrKeyur PatelJohn Scudderactivead-evalsub-pubBGP Extensions for Routing Policy Distribution (RPD)9821292024-03-20T00:48:09-07002024-03-20T00:48:09-0700Cindy MorganShepherding AD changed to John Scudderadded_commentietfidrKeyur PatelJohn Scudderactivewatchingwg-docPacket Content Filter for BGP FlowSpec9820322024-03-19T22:42:59-07002024-03-19T22:42:59-0700Yujia GaoNew version available: <b>draft-cui-idr-content-filter-flowspec-00.txt</b>new_revisionnoneactiveidexists The BGP Flow Specification enables the distribution of traffic filter
policies (traffic filters and actions) via BGP, facilitating DDoS
traffic filtering. However, the traffic filterer in FSv1 and FSv2
predominantly focuses on IP header fields, which may not adequately
address new types of DDoS attack traffic characterized by constant
patterns within the packet content. This document introduces a new
flow specification filter type designed for packet content filtering.
The match field includes offset-type, offset value, content-length,
and content-value, encoded in the Flowspec NLRI. This new filter
aims to augment DDoS defense capabilities.
00Packet Content Filter for BGP FlowSpec9820312024-03-19T22:42:59-07002024-03-19T22:42:59-0700Yujia GaoNew version accepted (logged-in submitter: Yujia Gao)new_submissionnoneactiveidexistsPacket Content Filter for BGP FlowSpec9820302024-03-19T22:40:01-07002024-03-19T22:40:01-0700Yujia GaoUploaded new revisionnew_submissionnoneactiveidexistsBorder Gateway Protocol 4 (BGP-4) Send Hold Timer9819442024-03-19T20:51:51-07002024-03-19T20:51:51-0700Job SnijdersNew version available: <b>draft-ietf-idr-bgp-sendholdtimer-03.txt</b>new_revisionietfidrSusan Haresactiveidexistswg-doc This document defines the SendHoldtimer and the SendHoldTimer Expired
events for the Border Gateway Protocol (BGP) Finite State Machine
(FSM). Implementation of the SendHoldTimer helps overcome situations
where a BGP session is not terminated after the local system detects
that the remote system is not processing BGP messages. This document
specifies that the local system should close the BGP connection and
not solely rely on the remote system for session closure when the
SendHoldTimer expires. This document updates RFC4271.
03Border Gateway Protocol 4 (BGP-4) Send Hold Timer9819432024-03-19T20:51:50-07002024-03-19T20:51:50-0700Job SnijdersNew version accepted (logged-in submitter: Job Snijders)new_submissionietfidrSusan Haresactiveidexistswg-docBorder Gateway Protocol 4 (BGP-4) Send Hold Timer9819422024-03-19T20:51:50-07002024-03-19T20:51:50-0700Job SnijdersUploaded new revisionnew_submissionietfidrSusan Haresactiveidexistswg-docAdvertising Segment Routing Policies in BGP9818912024-03-19T19:11:04-07002024-03-19T19:11:04-0700Susan Hares# Document Shepherd Write-Up for Group Documents<br>*This version is dated 4 July 2022.* [RFC4758] <br><br>Blocking issues: <br>1) Directorate reviews have issues (RTG-DIR, SEC-DIR, OPS-DIR). <br>2) NITs issues <br>3) implementation report <br><br>## Document History<br><br>1. Does the working group (WG) consensus represent the strong concurrence of a<br> few individuals, with others being silent, or did it reach broad agreement?<br><br>History - <br>6 steps: 1) 1st WG LC, 2) Wait for RFC7752, 3) AD review requires split (implemented/non-implemented), <br>4) review split (2nd WG LC), 5) Shepherd notes RFC9012 issues, 6) 3rd WG LC <br><br>Please note that the shepherd noted after the 2nd WG LC the issues with RFC9012. The final call was explicit that the RFC9012 format was used, but not the subTLVs and validation. <br><br>Dates: 1st: 8/06/2021, Split-IETF 3/15/2023, Split ok: 10/10-10/23/2023 (ok 10/23), <br>3rd WG LC: 2/15-3/18/2024<br>https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/<br>Result of WG LC (3/19/2024) <br>https://mailarchive.ietf.org/arch/msg/idr/rLJzLz_U8ZUuBaTBg7LIOh6CZ0o/<br><br>2. Was there controversy about particular points, or were there decisions where<br> the consensus was particularly rough?<br><br>At the 3rd WG LC, consensus was solid, but no comments were made on the <br>use of RFC9012. <br><br>3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If<br> so, please summarize the areas of conflict in separate email messages to the<br> responsible Area Director. (It should be in a separate email because this<br> questionnaire is publicly available.)<br><br>No discontent to 3rd WG LC. <br><br>4. For protocol documents, are there existing implementations of the contents of<br> the document? Have a significant number of potential implementers indicated<br> plans to implement? Are any existing implementations reported somewhere,<br> either in the document itself (as [RFC 7942][3] recommends) or elsewhere<br> (where)?<br>6 implementations (details on 5 implementations) <br>https://wiki.ietf.org/en/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement<br><br>## Additional Reviews<br><br>5. Do the contents of this document closely interact with technologies in other<br> IETF working groups or external organizations, and would it therefore benefit<br> from their review? Have those reviews occurred? If yes, describe which<br> reviews took place.<br><br>Requested Early Review of RTGDIR, OPSDIR, TSVART, SECDIR<br>Why OPSDIR + SECDIR: operational + security issues with the SR Candidate paths <br>Why TSVART: Link to the emerging Intent/Color routing work <br><br>Review as draft-ietf-idr-sr-policy-safi: <br>OPSDIR Early review (of -01) by Nagendra Nainar Has issues<br>RTGDIR Early review (of -00) by Zhaohui Zhang Has issues<br>TSVART Early review (of -00) by David Black On the Right Track<br>INTDIR Early Review due 2024-02-29 Requested<br><br>Waiting for checks on RTG-DIR, OPS-DIR. <br>Requesting SEC-DIR. <br><br>Review a draft-ietf-idr-segment-routing-te-policy<br>RTGDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Mohamed Boucadair Has issues<br>SECDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Vincent Roca Ready<br>INTDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Brian Haberman Ready w/issues<br><br>6. Describe how the document meets any required formal expert review criteria,<br> such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.<br><br>No formal review criteria - MIB, Yang, Media type, URI<br>Another Yang module needs to add this to the BGP Base. <br>Will add to IDR Wiki. <br><br>7. If the document contains a YANG module, has the final version of the module<br> been checked with any of the [recommended validation tools][4] for syntax and<br> formatting validation? If there are any resulting errors or warnings, what is<br> the justification for not fixing them at this time? Does the YANG module<br> comply with the Network Management Datastore Architecture (NMDA) as specified<br> in [RFC 8342][5]?<br><br>No Yang module. <br>Another Yang module needs to add this to the BGP Base. <br>Will add to IDR Wiki. <br><br>8. Describe reviews and automated checks performed to validate sections of the<br> final version of the document written in a formal language, such as XML code,<br> BNF rules, MIB definitions, CBOR's CDDL, etc.<br><br>No formal review <br><br>## Document Shepherd Checks<br><br>9. Based on the shepherd's review of the document, is it their opinion that this<br> document is needed, clearly written, complete, correctly designed, and ready<br> to be handed off to the responsible Area Director?<br><br>[TBD - ] <br><br>10. Several IETF Areas have assembled [lists of common issues that their<br> reviewers encounter][6]. For which areas have such issues been identified<br> and addressed? For which does this still need to happen in subsequent<br> reviews?<br><br>[TBD - need Routing list] <br><br>11. What type of RFC publication is being requested on the IETF stream ([Best<br> Current Practice][12], [Proposed Standard, Internet Standard][13],<br> [Informational, Experimental or Historic][14])? Why is this the proper type<br> of RFC? Do all Datatracker state attributes correctly reflect this intent?<br><br>Proposed standard - 6 implementations + SR work. <br>Issues - BGP does not do full validation <br><br>12. Have reasonable efforts been made to remind all authors of the intellectual<br> property rights (IPR) disclosure obligations described in [BCP 79][7]? To<br> the best of your knowledge, have all required disclosures been filed? If<br> not, explain why. If yes, summarize any relevant discussion, including links<br> to publicly-available messages when applicable.<br><br>Call for IPR <br>https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/<br> <br>1. Stefano Previdi<br>https://mailarchive.ietf.org/arch/msg/idr/URkVWm6k-mfSNqs9qYcfeISUR9c/<br><br>2. Clarence Filsfils<br>https://mailarchive.ietf.org/arch/msg/idr/PkArjfS7RJqGglyVXSGmoeTz8JQ/<br><br>3. Ketan Talaulikar, Ed.<br>https://mailarchive.ietf.org/arch/msg/idr/T2VaUQTIP0KqO5X3WGM6ThnlUQ8/<br><br>4. Paul Mattes<br>https://mailarchive.ietf.org/arch/msg/idr/TVTu_1hwgZozFLmHhfQnft5O7Kw/<br><br>5. Dhanendra Jain<br>https://mailarchive.ietf.org/arch/msg/idr/16MkEx6jVqfwUEGDtvtaKCPNBJg/<br><br>13. Has each author, editor, and contributor shown their willingness to be<br> listed as such? If the total number of authors and editors on the front page<br> is greater than five, please provide a justification.<br><br>Total number of authors: 5, <br>No contributors. <br><br>14. Document any remaining I-D nits in this document. Simply running the [idnits<br> tool][8] is not enough; please review the ["Content Guidelines" on<br> authors.ietf.org][15]. (Also note that the current idnits tool generates<br> some incorrect warnings; a rewrite is underway.)<br>[run extensive I-D nits]<br><br>15. Should any informative references be normative or vice-versa? See the [IESG<br> Statement on Normative and Informative References][16].<br><br>16. List any normative references that are not freely available to anyone. Did<br> the community have sufficient access to review any such normative<br> references?<br>[TBD] <br><br>17. Are there any normative downward references (see [RFC 3967][9] and [BCP<br> 97][10]) that are not already listed in the [DOWNREF registry][17]? If so,<br> list them.<br>[TBD] <br><br>18. Are there normative references to documents that are not ready to be<br> submitted to the IESG for publication or are otherwise in an unclear state?<br> If so, what is the plan for their completion?<br><br>[TBD] <br><br>19. Will publication of this document change the status of any existing RFCs? If<br> so, does the Datatracker metadata correctly reflect this and are those RFCs<br> listed on the title page, in the abstract, and discussed in the<br> introduction? If not, explain why and point to the part of the document<br> where the relationship of this document to these other RFCs is discussed.<br><br>Yes - [RFC9012] <br><br>20. Describe the document shepherd's review of the IANA considerations section,<br> especially with regard to its consistency with the body of the document.<br> Confirm that all aspects of the document requiring IANA assignments are<br> associated with the appropriate reservations in IANA registries. Confirm<br> that any referenced IANA registries have been clearly identified. Confirm<br> that each newly created IANA registry specifies its initial contents,<br> allocations procedures, and a reasonable name (see [RFC 8126][11]).<br><br>21. List any new IANA registries that require Designated Expert Review for<br> future allocations. Are the instructions to the Designated Expert clear?<br> Please include suggestions of designated experts, if appropriate.<br><br>[TBD] <br><br>[1]: https://www.ietf.org/about/groups/iesg/<br>[2]: https://www.rfc-editor.org/rfc/rfc4858.html<br>[3]: https://www.rfc-editor.org/rfc/rfc7942.html<br>[4]: https://wiki.ietf.org/group/ops/yang-review-tools<br>[5]: https://www.rfc-editor.org/rfc/rfc8342.html<br>[6]: https://wiki.ietf.org/group/iesg/ExpertTopics<br>[7]: https://www.rfc-editor.org/info/bcp79<br>[8]: https://www.ietf.org/tools/idnits/<br>[9]: https://www.rfc-editor.org/rfc/rfc3967.html<br>[10]: https://www.rfc-editor.org/info/bcp97<br>[11]: https://www.rfc-editor.org/rfc/rfc8126.html<br>[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5<br>[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1<br>[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2<br>[15]: https://authors.ietf.org/en/content-guidelines-overview<br>[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/<br>[17]: https://datatracker.ietf.org/doc/downref/<br><br>changed_protocol_writeupietfidrSusan HaresactiveidexistswriteupwAdvertising Segment Routing Policies in BGP9818662024-03-19T18:27:34-07002024-03-19T18:27:34-0700Susan Hares# Document Shepherd Write-Up for Group Documents<br><br>*This version is dated 4 July 2022.* [RFC4758] <br><br>## Document History<br><br>1. Does the working group (WG) consensus represent the strong concurrence of a<br> few individuals, with others being silent, or did it reach broad agreement?<br><br>History - <br>6 steps: 1) 1st WG LC, 2) Wait for RFC7752, 3) AD review requires split (implemented/non-implemented), <br>4) review split (2nd WG LC), 5) Shepherd notes RFC9012 issues, 6) 3rd WG LC <br><br>Please note that the shepherd noted after the 2nd WG LC the issues with RFC9012. The final call was explicit that the RFC9012 format was used, but not the subTLVs and validation. <br><br>Dates: 1st: 8/06/2021, Split-IETF 3/15/2023, Split ok: 10/10-10/23/2023 (ok 10/23), <br>3rd WG LC: 2/15-3/18/2024<br>https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/<br>Result of WG LC (3/19/2024) <br>https://mailarchive.ietf.org/arch/msg/idr/rLJzLz_U8ZUuBaTBg7LIOh6CZ0o/<br><br>2. Was there controversy about particular points, or were there decisions where<br> the consensus was particularly rough?<br><br>At the 3rd WG LC, consensus was solid, but no comments were made on the <br>use of RFC9012. <br><br>3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If<br> so, please summarize the areas of conflict in separate email messages to the<br> responsible Area Director. (It should be in a separate email because this<br> questionnaire is publicly available.)<br><br>No discontent to 3rd WG LC. <br><br>4. For protocol documents, are there existing implementations of the contents of<br> the document? Have a significant number of potential implementers indicated<br> plans to implement? Are any existing implementations reported somewhere,<br> either in the document itself (as [RFC 7942][3] recommends) or elsewhere<br> (where)?<br>6 implementations (details on 5 implementations) <br>https://wiki.ietf.org/en/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement<br><br>## Additional Reviews<br><br>5. Do the contents of this document closely interact with technologies in other<br> IETF working groups or external organizations, and would it therefore benefit<br> from their review? Have those reviews occurred? If yes, describe which<br> reviews took place.<br><br>Requested Early Review of RTGDIR, OPSDIR, TSVART, SECDIR<br>Why OPSDIR + SECDIR: operational + security issues with the SR Candidate paths <br>Why TSVART: Link to the emerging Intent/Color routing work <br>RTG<br><br>Review as draft-ietf-idr-sr-policy-safi: <br>OPSDIR Early review (of -01) by Nagendra Nainar Has issues<br>RTGDIR Early review (of -00) by Zhaohui Zhang Has issues<br>TSVART Early review (of -00) by David Black On the Right Track<br>INTDIR Early Review due 2024-02-29 Requested<br><br>Waiting for checks on RTG-DIR, OPS-DIR. <br>Requesting SEC-DIR. <br><br>Review a draft-ietf-idr-segment-routing-te-policy<br>RTGDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Mohamed Boucadair Has issues<br>SECDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Vincent Roca Ready<br>INTDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Brian Haberman Ready w/issues<br><br><br><br>6. Describe how the document meets any required formal expert review criteria,<br> such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.<br><br>No formal review criteria - MIB, Yang, Media type, URI<br>Another Yang module needs to add this to the BGP Base. <br>Will add to IDR Wiki. <br><br>7. If the document contains a YANG module, has the final version of the module<br> been checked with any of the [recommended validation tools][4] for syntax and<br> formatting validation? If there are any resulting errors or warnings, what is<br> the justification for not fixing them at this time? Does the YANG module<br> comply with the Network Management Datastore Architecture (NMDA) as specified<br> in [RFC 8342][5]?<br><br>No Yang module. <br>Another Yang module needs to add this to the BGP Base. <br>Will add to IDR Wiki. <br><br>8. Describe reviews and automated checks performed to validate sections of the<br> final version of the document written in a formal language, such as XML code,<br> BNF rules, MIB definitions, CBOR's CDDL, etc.<br><br>No formal review <br><br>## Document Shepherd Checks<br><br>9. Based on the shepherd's review of the document, is it their opinion that this<br> document is needed, clearly written, complete, correctly designed, and ready<br> to be handed off to the responsible Area Director?<br><br>[TBD - links to Shephd rreviews] <br><br>10. Several IETF Areas have assembled [lists of common issues that their<br> reviewers encounter][6]. For which areas have such issues been identified<br> and addressed? For which does this still need to happen in subsequent<br> reviews?<br><br>[TBD - need Routing list] <br><br>11. What type of RFC publication is being requested on the IETF stream ([Best<br> Current Practice][12], [Proposed Standard, Internet Standard][13],<br> [Informational, Experimental or Historic][14])? Why is this the proper type<br> of RFC? Do all Datatracker state attributes correctly reflect this intent?<br><br>Proposed standard - 6 implementations + SR work. <br>Issues - BGP does not do full validation <br><br>12. Have reasonable efforts been made to remind all authors of the intellectual<br> property rights (IPR) disclosure obligations described in [BCP 79][7]? To<br> the best of your knowledge, have all required disclosures been filed? If<br> not, explain why. If yes, summarize any relevant discussion, including links<br> to publicly-available messages when applicable.<br><br>Call for IPR <br>https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/<br> <br>1. Stefano Previdi<br>https://mailarchive.ietf.org/arch/msg/idr/URkVWm6k-mfSNqs9qYcfeISUR9c/<br><br>2. Clarence Filsfils<br>https://mailarchive.ietf.org/arch/msg/idr/PkArjfS7RJqGglyVXSGmoeTz8JQ/<br><br>3. Ketan Talaulikar, Ed.<br>https://mailarchive.ietf.org/arch/msg/idr/T2VaUQTIP0KqO5X3WGM6ThnlUQ8/<br><br>4. Paul Mattes<br>https://mailarchive.ietf.org/arch/msg/idr/TVTu_1hwgZozFLmHhfQnft5O7Kw/<br><br>5. Dhanendra Jain<br>https://mailarchive.ietf.org/arch/msg/idr/16MkEx6jVqfwUEGDtvtaKCPNBJg/<br><br>13. Has each author, editor, and contributor shown their willingness to be<br> listed as such? If the total number of authors and editors on the front page<br> is greater than five, please provide a justification.<br><br>Total number of authors: 5, <br>No contributors. <br><br>14. Document any remaining I-D nits in this document. Simply running the [idnits<br> tool][8] is not enough; please review the ["Content Guidelines" on<br> authors.ietf.org][15]. (Also note that the current idnits tool generates<br> some incorrect warnings; a rewrite is underway.)<br>[run extensive I-D nits]<br><br>15. Should any informative references be normative or vice-versa? See the [IESG<br> Statement on Normative and Informative References][16].<br><br>16. List any normative references that are not freely available to anyone. Did<br> the community have sufficient access to review any such normative<br> references?<br>[TBD] <br><br>17. Are there any normative downward references (see [RFC 3967][9] and [BCP<br> 97][10]) that are not already listed in the [DOWNREF registry][17]? If so,<br> list them.<br>[TBD] <br><br>18. Are there normative references to documents that are not ready to be<br> submitted to the IESG for publication or are otherwise in an unclear state?<br> If so, what is the plan for their completion?<br><br>[TBD] <br><br>19. Will publication of this document change the status of any existing RFCs? If<br> so, does the Datatracker metadata correctly reflect this and are those RFCs<br> listed on the title page, in the abstract, and discussed in the<br> introduction? If not, explain why and point to the part of the document<br> where the relationship of this document to these other RFCs is discussed.<br><br>Yes - [RFC9012] <br><br>20. Describe the document shepherd's review of the IANA considerations section,<br> especially with regard to its consistency with the body of the document.<br> Confirm that all aspects of the document requiring IANA assignments are<br> associated with the appropriate reservations in IANA registries. Confirm<br> that any referenced IANA registries have been clearly identified. Confirm<br> that each newly created IANA registry specifies its initial contents,<br> allocations procedures, and a reasonable name (see [RFC 8126][11]).<br><br>21. List any new IANA registries that require Designated Expert Review for<br> future allocations. Are the instructions to the Designated Expert clear?<br> Please include suggestions of designated experts, if appropriate.<br><br>[TBD] <br><br>[1]: https://www.ietf.org/about/groups/iesg/<br>[2]: https://www.rfc-editor.org/rfc/rfc4858.html<br>[3]: https://www.rfc-editor.org/rfc/rfc7942.html<br>[4]: https://wiki.ietf.org/group/ops/yang-review-tools<br>[5]: https://www.rfc-editor.org/rfc/rfc8342.html<br>[6]: https://wiki.ietf.org/group/iesg/ExpertTopics<br>[7]: https://www.rfc-editor.org/info/bcp79<br>[8]: https://www.ietf.org/tools/idnits/<br>[9]: https://www.rfc-editor.org/rfc/rfc3967.html<br>[10]: https://www.rfc-editor.org/info/bcp97<br>[11]: https://www.rfc-editor.org/rfc/rfc8126.html<br>[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5<br>[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1<br>[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2<br>[15]: https://authors.ietf.org/en/content-guidelines-overview<br>[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/<br>[17]: https://datatracker.ietf.org/doc/downref/<br><br>changed_protocol_writeupietfidrSusan HaresactiveidexistswriteupwAdvertising Segment Routing Policies in BGP9818652024-03-19T18:23:38-07002024-03-19T18:23:38-0700Susan Hares# Document Shepherd Write-Up for Group Documents<br><br>*This version is dated 4 July 2022.* [RFC4758] <br><br>## Document History<br><br>1. Does the working group (WG) consensus represent the strong concurrence of a<br> few individuals, with others being silent, or did it reach broad agreement?<br><br>History - <br>6 steps: 1) 1st WG LC, 2) Wait for RFC7752, 3) AD review requires split (implemented/non-implemented), <br>4) review split (2nd WG LC), 5) Shepherd notes RFC9012 issues, 6) 3rd WG LC <br><br>Please note that the shepherd noted after the 2nd WG LC the issues with RFC9012. The final call was explicit that the RFC9012 format was used, but not the subTLVs and validation. <br><br>Dates: 1st: 8/06/2021, Split-IETF 3/15/2023, Split ok: 10/10-10/23/2023 (ok 10/23), <br>3rd WG LC: 2/15-3/18/2024<br>https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/<br>Result of WG LC (3/19/2024) <br>https://mailarchive.ietf.org/arch/msg/idr/rLJzLz_U8ZUuBaTBg7LIOh6CZ0o/<br><br>2. Was there controversy about particular points, or were there decisions where<br> the consensus was particularly rough?<br><br>At the 3rd WG LC, consensus was solid, but no comments were made on the <br>use of RFC9012. <br><br>3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If<br> so, please summarize the areas of conflict in separate email messages to the<br> responsible Area Director. (It should be in a separate email because this<br> questionnaire is publicly available.)<br><br>No discontent to 3rd WG LC. <br><br>4. For protocol documents, are there existing implementations of the contents of<br> the document? Have a significant number of potential implementers indicated<br> plans to implement? Are any existing implementations reported somewhere,<br> either in the document itself (as [RFC 7942][3] recommends) or elsewhere<br> (where)?<br>6 implementations (details on 5 implementations) <br>https://wiki.ietf.org/en/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement<br><br>## Additional Reviews<br><br>5. Do the contents of this document closely interact with technologies in other<br> IETF working groups or external organizations, and would it therefore benefit<br> from their review? Have those reviews occurred? If yes, describe which<br> reviews took place.<br><br>Requested Early Review of RTGDIR, OPSDIR, TSVART, SECDIR<br>Why OPSDIR + SECDIR: operational + security issues with the SR Candidate paths <br>Why TSVART: Link to the emerging Intent/Color routing work <br>RTG<br><br>Review as draft-ietf-idr-sr-policy-safi: <br>OPSDIR Early review (of -01) by Nagendra Nainar Has issues<br>RTGDIR Early review (of -00) by Zhaohui Zhang Has issues<br>TSVART Early review (of -00) by David Black On the Right Track<br>INTDIR Early Review due 2024-02-29 Requested<br><br>Waiting for checks on RTG-DIR, OPS-DIR. <br>Requesting SEC-DIR. <br><br>Review a draft-ietf-idr-segment-routing-te-policy<br>RTGDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Mohamed Boucadair Has issues<br>SECDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Vincent Roca Ready<br>INTDIR Early review (of draft-ietf-idr-segment-routing-te-policy -18) by Brian Haberman Ready w/issues<br><br><br><br>6. Describe how the document meets any required formal expert review criteria,<br> such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.<br><br>No formal review criteria - MIB, Yang, Media type, URI<br>Another Yang module needs to add this to the BGP Base. <br>Will add to IDR Wiki. <br><br>7. If the document contains a YANG module, has the final version of the module<br> been checked with any of the [recommended validation tools][4] for syntax and<br> formatting validation? If there are any resulting errors or warnings, what is<br> the justification for not fixing them at this time? Does the YANG module<br> comply with the Network Management Datastore Architecture (NMDA) as specified<br> in [RFC 8342][5]?<br><br>No Yang module. <br>Another Yang module needs to add this to the BGP Base. <br>Will add to IDR Wiki. <br><br>8. Describe reviews and automated checks performed to validate sections of the<br> final version of the document written in a formal language, such as XML code,<br> BNF rules, MIB definitions, CBOR's CDDL, etc.<br><br>No formal review <br><br>## Document Shepherd Checks<br><br>9. Based on the shepherd's review of the document, is it their opinion that this<br> document is needed, clearly written, complete, correctly designed, and ready<br> to be handed off to the responsible Area Director?<br><br>[TBD - links to Shephd rreviews] <br><br>10. Several IETF Areas have assembled [lists of common issues that their<br> reviewers encounter][6]. For which areas have such issues been identified<br> and addressed? For which does this still need to happen in subsequent<br> reviews?<br><br>[TBD - need Routing list] <br><br>11. What type of RFC publication is being requested on the IETF stream ([Best<br> Current Practice][12], [Proposed Standard, Internet Standard][13],<br> [Informational, Experimental or Historic][14])? Why is this the proper type<br> of RFC? Do all Datatracker state attributes correctly reflect this intent?<br><br>Proposed standard - 6 implementations + SR work. <br>Issues - BGP does not do full validation <br><br>12. Have reasonable efforts been made to remind all authors of the intellectual<br> property rights (IPR) disclosure obligations described in [BCP 79][7]? To<br> the best of your knowledge, have all required disclosures been filed? If<br> not, explain why. If yes, summarize any relevant discussion, including links<br> to publicly-available messages when applicable.<br><br>Call for IPR <br>https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/<br> <br>1. Stefano Previdi<br>https://mailarchive.ietf.org/arch/msg/idr/URkVWm6k-mfSNqs9qYcfeISUR9c/<br><br>2. Clarence Filsfils<br>https://mailarchive.ietf.org/arch/msg/idr/PkArjfS7RJqGglyVXSGmoeTz8JQ/<br><br>3. Ketan Talaulikar, Ed.<br>https://mailarchive.ietf.org/arch/msg/idr/T2VaUQTIP0KqO5X3WGM6ThnlUQ8/<br><br>4. Paul Mattes<br>https://mailarchive.ietf.org/arch/msg/idr/TVTu_1hwgZozFLmHhfQnft5O7Kw/<br><br>5. Dhanendra Jain<br>https://mailarchive.ietf.org/arch/msg/idr/16MkEx6jVqfwUEGDtvtaKCPNBJg/<br><br>13. Has each author, editor, and contributor shown their willingness to be<br> listed as such? If the total number of authors and editors on the front page<br> is greater than five, please provide a justification.<br><br>Total number of authors: 5, <br>No contributors. <br><br>14. Document any remaining I-D nits in this document. Simply running the [idnits<br> tool][8] is not enough; please review the ["Content Guidelines" on<br> authors.ietf.org][15]. (Also note that the current idnits tool generates<br> some incorrect warnings; a rewrite is underway.)<br>[run extensive I-D nits]<br><br>15. Should any informative references be normative or vice-versa? See the [IESG<br> Statement on Normative and Informative References][16].<br><br>16. List any normative references that are not freely available to anyone. Did<br> the community have sufficient access to review any such normative<br> references?<br>[TBD] <br><br>17. Are there any normative downward references (see [RFC 3967][9] and [BCP<br> 97][10]) that are not already listed in the [DOWNREF registry][17]? If so,<br> list them.<br>[TBD] <br><br>18. Are there normative references to documents that are not ready to be<br> submitted to the IESG for publication or are otherwise in an unclear state?<br> If so, what is the plan for their completion?<br><br>[TBD] <br><br>19. Will publication of this document change the status of any existing RFCs? If<br> so, does the Datatracker metadata correctly reflect this and are those RFCs<br> listed on the title page, in the abstract, and discussed in the<br> introduction? If not, explain why and point to the part of the document<br> where the relationship of this document to these other RFCs is discussed.<br><br>Yes - [RFC9012] <br><br>20. Describe the document shepherd's review of the IANA considerations section,<br> especially with regard to its consistency with the body of the document.<br> Confirm that all aspects of the document requiring IANA assignments are<br> associated with the appropriate reservations in IANA registries. Confirm<br> that any referenced IANA registries have been clearly identified. Confirm<br> that each newly created IANA registry specifies its initial contents,<br> allocations procedures, and a reasonable name (see [RFC 8126][11]).<br><br>21. List any new IANA registries that require Designated Expert Review for<br> future allocations. Are the instructions to the Designated Expert clear?<br> Please include suggestions of designated experts, if appropriate.<br><br>[TBD] <br><br>[1]: https://www.ietf.org/about/groups/iesg/<br>[2]: https://www.rfc-editor.org/rfc/rfc4858.html<br>[3]: https://www.rfc-editor.org/rfc/rfc7942.html<br>[4]: https://wiki.ietf.org/group/ops/yang-review-tools<br>[5]: https://www.rfc-editor.org/rfc/rfc8342.html<br>[6]: https://wiki.ietf.org/group/iesg/ExpertTopics<br>[7]: https://www.rfc-editor.org/info/bcp79<br>[8]: https://www.ietf.org/tools/idnits/<br>[9]: https://www.rfc-editor.org/rfc/rfc3967.html<br>[10]: https://www.rfc-editor.org/info/bcp97<br>[11]: https://www.rfc-editor.org/rfc/rfc8126.html<br>[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5<br>[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1<br>[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2<br>[15]: https://authors.ietf.org/en/content-guidelines-overview<br>[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/<br>[17]: https://datatracker.ietf.org/doc/downref/<br><br>changed_protocol_writeupietfidrSusan HaresactiveidexistswriteupwAdvertising Segment Routing Policies in BGP9818412024-03-19T18:11:43-07002024-03-19T18:11:43-0700Susan Hares# Document Shepherd Write-Up for Group Documents<br><br>*This version is dated 4 July 2022.* [RFC4758] <br><br>## Document History<br><br>1. Does the working group (WG) consensus represent the strong concurrence of a<br> few individuals, with others being silent, or did it reach broad agreement?<br><br>History - <br>6 steps: 1) 1st WG LC, 2) Wait for RFC7752, 3) AD review requires split (implemented/non-implemented), <br>4) review split (2nd WG LC), 5) Shepherd notes RFC9012 issues, 6) 3rd WG LC <br><br>Please note that the shepherd noted after the 2nd WG LC the issues with RFC9012. The final call was explicit that the RFC9012 format was used, but not the subTLVs and validation. <br><br>Dates: 1st: 8/06/2021, Split-IETF 3/15/2023, Split ok: 10/10-10/23/2023 (ok 10/23), <br>3rd WG LC: 2/15-3/18/2024<br>https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/<br>Result of WG LC (3/19/2024) <br>https://mailarchive.ietf.org/arch/msg/idr/rLJzLz_U8ZUuBaTBg7LIOh6CZ0o/<br><br>2. Was there controversy about particular points, or were there decisions where<br> the consensus was particularly rough?<br><br>At the 3rd WG LC, consensus was solid, but no comments were made on the <br>use of RFC9012. <br><br>3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If<br> so, please summarize the areas of conflict in separate email messages to the<br> responsible Area Director. (It should be in a separate email because this<br> questionnaire is publicly available.)<br><br>No discontent to 3rd WG LC. <br><br>4. For protocol documents, are there existing implementations of the contents of<br> the document? Have a significant number of potential implementers indicated<br> plans to implement? Are any existing implementations reported somewhere,<br> either in the document itself (as [RFC 7942][3] recommends) or elsewhere<br> (where)?<br>6 implementations <br>https://wiki.ietf.org/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement<br><br>## Additional Reviews<br><br>5. Do the contents of this document closely interact with technologies in other<br> IETF working groups or external organizations, and would it therefore benefit<br> from their review? Have those reviews occurred? If yes, describe which<br> reviews took place.<br><br>Requested Early Review of RTGDIR, OPSDIR, TSVART, SECDIR<br>Why OPSDIR + SECDIR: operational + security issues with the SR Candidate paths <br>Why TSVART: Link to the emerging Intent/Color routing work <br>RTG<br><br>6. Describe how the document meets any required formal expert review criteria,<br> such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.<br><br>No formal review criteria - MIB, Yang, Media type, URI<br>Another Yang module needs to add this to the BGP Base. <br>Will add to IDR Wiki. <br><br>7. If the document contains a YANG module, has the final version of the module<br> been checked with any of the [recommended validation tools][4] for syntax and<br> formatting validation? If there are any resulting errors or warnings, what is<br> the justification for not fixing them at this time? Does the YANG module<br> comply with the Network Management Datastore Architecture (NMDA) as specified<br> in [RFC 8342][5]?<br><br>No Yang module. <br>Another Yang module needs to add this to the BGP Base. <br>Will add to IDR Wiki. <br><br>8. Describe reviews and automated checks performed to validate sections of the<br> final version of the document written in a formal language, such as XML code,<br> BNF rules, MIB definitions, CBOR's CDDL, etc.<br><br>No formal review <br><br>## Document Shepherd Checks<br><br>9. Based on the shepherd's review of the document, is it their opinion that this<br> document is needed, clearly written, complete, correctly designed, and ready<br> to be handed off to the responsible Area Director?<br><br>[TBD - links to Shephd rreviews] <br><br>10. Several IETF Areas have assembled [lists of common issues that their<br> reviewers encounter][6]. For which areas have such issues been identified<br> and addressed? For which does this still need to happen in subsequent<br> reviews?<br><br>[TBD - need Routing list] <br><br>11. What type of RFC publication is being requested on the IETF stream ([Best<br> Current Practice][12], [Proposed Standard, Internet Standard][13],<br> [Informational, Experimental or Historic][14])? Why is this the proper type<br> of RFC? Do all Datatracker state attributes correctly reflect this intent?<br><br>Proposed standard - 6 implementations + SR work. <br>Issues - BGP does not do full validation <br><br>12. Have reasonable efforts been made to remind all authors of the intellectual<br> property rights (IPR) disclosure obligations described in [BCP 79][7]? To<br> the best of your knowledge, have all required disclosures been filed? If<br> not, explain why. If yes, summarize any relevant discussion, including links<br> to publicly-available messages when applicable.<br><br>Call for IPR <br>https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/<br> <br>1. Stefano Previdi<br>https://mailarchive.ietf.org/arch/msg/idr/URkVWm6k-mfSNqs9qYcfeISUR9c/<br><br>2. Clarence Filsfils<br>https://mailarchive.ietf.org/arch/msg/idr/PkArjfS7RJqGglyVXSGmoeTz8JQ/<br><br>3. Ketan Talaulikar, Ed.<br>https://mailarchive.ietf.org/arch/msg/idr/T2VaUQTIP0KqO5X3WGM6ThnlUQ8/<br><br>4. Paul Mattes<br>https://mailarchive.ietf.org/arch/msg/idr/TVTu_1hwgZozFLmHhfQnft5O7Kw/<br><br>5. Dhanendra Jain<br>https://mailarchive.ietf.org/arch/msg/idr/16MkEx6jVqfwUEGDtvtaKCPNBJg/<br><br>13. Has each author, editor, and contributor shown their willingness to be<br> listed as such? If the total number of authors and editors on the front page<br> is greater than five, please provide a justification.<br><br>Total number of authors: 5, <br>No contributors. <br><br>14. Document any remaining I-D nits in this document. Simply running the [idnits<br> tool][8] is not enough; please review the ["Content Guidelines" on<br> authors.ietf.org][15]. (Also note that the current idnits tool generates<br> some incorrect warnings; a rewrite is underway.)<br>[run extensive I-D nits]<br><br>15. Should any informative references be normative or vice-versa? See the [IESG<br> Statement on Normative and Informative References][16].<br><br>16. List any normative references that are not freely available to anyone. Did<br> the community have sufficient access to review any such normative<br> references?<br>[TBD] <br><br>17. Are there any normative downward references (see [RFC 3967][9] and [BCP<br> 97][10]) that are not already listed in the [DOWNREF registry][17]? If so,<br> list them.<br>[TBD] <br><br>18. Are there normative references to documents that are not ready to be<br> submitted to the IESG for publication or are otherwise in an unclear state?<br> If so, what is the plan for their completion?<br><br>[TBD] <br><br>19. Will publication of this document change the status of any existing RFCs? If<br> so, does the Datatracker metadata correctly reflect this and are those RFCs<br> listed on the title page, in the abstract, and discussed in the<br> introduction? If not, explain why and point to the part of the document<br> where the relationship of this document to these other RFCs is discussed.<br><br>Yes - [RFC9012] <br><br>20. Describe the document shepherd's review of the IANA considerations section,<br> especially with regard to its consistency with the body of the document.<br> Confirm that all aspects of the document requiring IANA assignments are<br> associated with the appropriate reservations in IANA registries. Confirm<br> that any referenced IANA registries have been clearly identified. Confirm<br> that each newly created IANA registry specifies its initial contents,<br> allocations procedures, and a reasonable name (see [RFC 8126][11]).<br><br>21. List any new IANA registries that require Designated Expert Review for<br> future allocations. Are the instructions to the Designated Expert clear?<br> Please include suggestions of designated experts, if appropriate.<br><br>[TBD] <br><br>[1]: https://www.ietf.org/about/groups/iesg/<br>[2]: https://www.rfc-editor.org/rfc/rfc4858.html<br>[3]: https://www.rfc-editor.org/rfc/rfc7942.html<br>[4]: https://wiki.ietf.org/group/ops/yang-review-tools<br>[5]: https://www.rfc-editor.org/rfc/rfc8342.html<br>[6]: https://wiki.ietf.org/group/iesg/ExpertTopics<br>[7]: https://www.rfc-editor.org/info/bcp79<br>[8]: https://www.ietf.org/tools/idnits/<br>[9]: https://www.rfc-editor.org/rfc/rfc3967.html<br>[10]: https://www.rfc-editor.org/info/bcp97<br>[11]: https://www.rfc-editor.org/rfc/rfc8126.html<br>[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5<br>[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1<br>[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2<br>[15]: https://authors.ietf.org/en/content-guidelines-overview<br>[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/<br>[17]: https://datatracker.ietf.org/doc/downref/<br><br>changed_protocol_writeupietfidrSusan HaresactiveidexistswriteupwAdvertising Segment Routing Policies in BGP9817742024-03-19T16:57:46-07002024-03-19T16:57:46-0700Susan Hares# Document Shepherd Write-Up for Group Documents<br><br>*This version is dated 4 July 2022.* [RFC4758] <br><br>## Document History<br><br>1. Does the working group (WG) consensus represent the strong concurrence of a<br> few individuals, with others being silent, or did it reach broad agreement?<br><br>History - <br>6 steps: 1) 1st WG LC, 2) Wait for RFC7752, 3) AD review requires split (implemented/non-implemented), <br>4) review split (2nd WG LC), 5) Shepherd notes RFC9012 issues, 6) 3rd WG LC <br>Dates: 1st: 8/06/2021, Split-IETF 3/15/2023, Split ok: 10/10-10/23/2023 (ok 10/23), <br>3rd WG LC: 2/15-3/18/2024<br>https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/<br>Result of WG LC (3/19/2024) <br>https://mailarchive.ietf.org/arch/msg/idr/rLJzLz_U8ZUuBaTBg7LIOh6CZ0o/<br><br>2. Was there controversy about particular points, or were there decisions where<br> the consensus was particularly rough?<br><br>At the 3rd WG LC, consensus was solid. <br><br>3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If<br> so, please summarize the areas of conflict in separate email messages to the<br> responsible Area Director. (It should be in a separate email because this<br> questionnaire is publicly available.)<br><br>No discontent to 3rd WG LC. <br><br>4. For protocol documents, are there existing implementations of the contents of<br> the document? Have a significant number of potential implementers indicated<br> plans to implement? Are any existing implementations reported somewhere,<br> either in the document itself (as [RFC 7942][3] recommends) or elsewhere<br> (where)?<br>6 implementations <br>https://wiki.ietf.org/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement<br><br>## Additional Reviews<br><br>5. Do the contents of this document closely interact with technologies in other<br> IETF working groups or external organizations, and would it therefore benefit<br> from their review? Have those reviews occurred? If yes, describe which<br> reviews took place.<br><br>Requested Early Review of RTGDIR, OPSDIR, TSVART, SECDIR<br>Why OPSDIR + SECDIR: operational + security issues with the SR Candidate paths <br>Why TSVART: Link to the emerging Intent/Color routing work <br>RTG<br><br>6. Describe how the document meets any required formal expert review criteria,<br> such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.<br><br>No formal review criteria - MIB, Yang, Media type, URI<br>Another Yang module needs to add this to the BGP Base. <br>Will add to IDR Wiki. <br><br>7. If the document contains a YANG module, has the final version of the module<br> been checked with any of the [recommended validation tools][4] for syntax and<br> formatting validation? If there are any resulting errors or warnings, what is<br> the justification for not fixing them at this time? Does the YANG module<br> comply with the Network Management Datastore Architecture (NMDA) as specified<br> in [RFC 8342][5]?<br><br>No Yang module. <br>Another Yang module needs to add this to the BGP Base. <br>Will add to IDR Wiki. <br><br>8. Describe reviews and automated checks performed to validate sections of the<br> final version of the document written in a formal language, such as XML code,<br> BNF rules, MIB definitions, CBOR's CDDL, etc.<br><br>No formal review <br><br>## Document Shepherd Checks<br><br>9. Based on the shepherd's review of the document, is it their opinion that this<br> document is needed, clearly written, complete, correctly designed, and ready<br> to be handed off to the responsible Area Director?<br><br>[TBD - links to Shephd rreviews] <br><br>10. Several IETF Areas have assembled [lists of common issues that their<br> reviewers encounter][6]. For which areas have such issues been identified<br> and addressed? For which does this still need to happen in subsequent<br> reviews?<br><br>[TBD - need Routing list] <br><br>11. What type of RFC publication is being requested on the IETF stream ([Best<br> Current Practice][12], [Proposed Standard, Internet Standard][13],<br> [Informational, Experimental or Historic][14])? Why is this the proper type<br> of RFC? Do all Datatracker state attributes correctly reflect this intent?<br><br>Proposed standard - 6 implementations + SR work. <br>Issues - BGP does not do full validation <br><br>12. Have reasonable efforts been made to remind all authors of the intellectual<br> property rights (IPR) disclosure obligations described in [BCP 79][7]? To<br> the best of your knowledge, have all required disclosures been filed? If<br> not, explain why. If yes, summarize any relevant discussion, including links<br> to publicly-available messages when applicable.<br><br>Call for IPR <br>https://mailarchive.ietf.org/arch/msg/idr/b8VABzT4fTyvY0j6_FuA04RYiHY/<br> <br>1. Stefano Previdi<br>https://mailarchive.ietf.org/arch/msg/idr/URkVWm6k-mfSNqs9qYcfeISUR9c/<br><br>2. Clarence Filsfils<br>https://mailarchive.ietf.org/arch/msg/idr/PkArjfS7RJqGglyVXSGmoeTz8JQ/<br><br>3. Ketan Talaulikar, Ed.<br>https://mailarchive.ietf.org/arch/msg/idr/T2VaUQTIP0KqO5X3WGM6ThnlUQ8/<br><br>4. Paul Mattes<br>https://mailarchive.ietf.org/arch/msg/idr/TVTu_1hwgZozFLmHhfQnft5O7Kw/<br><br>5. Dhanendra Jain<br>https://mailarchive.ietf.org/arch/msg/idr/16MkEx6jVqfwUEGDtvtaKCPNBJg/<br><br>13. Has each author, editor, and contributor shown their willingness to be<br> listed as such? If the total number of authors and editors on the front page<br> is greater than five, please provide a justification.<br><br>Total number of authors: 5, <br>No contributors. <br><br>14. Document any remaining I-D nits in this document. Simply running the [idnits<br> tool][8] is not enough; please review the ["Content Guidelines" on<br> authors.ietf.org][15]. (Also note that the current idnits tool generates<br> some incorrect warnings; a rewrite is underway.)<br>[run extensive I-D nits]<br><br>15. Should any informative references be normative or vice-versa? See the [IESG<br> Statement on Normative and Informative References][16].<br><br>16. List any normative references that are not freely available to anyone. Did<br> the community have sufficient access to review any such normative<br> references?<br>[TBD] <br><br>17. Are there any normative downward references (see [RFC 3967][9] and [BCP<br> 97][10]) that are not already listed in the [DOWNREF registry][17]? If so,<br> list them.<br>[TBD] <br><br>18. Are there normative references to documents that are not ready to be<br> submitted to the IESG for publication or are otherwise in an unclear state?<br> If so, what is the plan for their completion?<br><br>[TBD] <br><br>19. Will publication of this document change the status of any existing RFCs? If<br> so, does the Datatracker metadata correctly reflect this and are those RFCs<br> listed on the title page, in the abstract, and discussed in the<br> introduction? If not, explain why and point to the part of the document<br> where the relationship of this document to these other RFCs is discussed.<br><br>Yes - [RFC9012] <br><br>20. Describe the document shepherd's review of the IANA considerations section,<br> especially with regard to its consistency with the body of the document.<br> Confirm that all aspects of the document requiring IANA assignments are<br> associated with the appropriate reservations in IANA registries. Confirm<br> that any referenced IANA registries have been clearly identified. Confirm<br> that each newly created IANA registry specifies its initial contents,<br> allocations procedures, and a reasonable name (see [RFC 8126][11]).<br><br>21. List any new IANA registries that require Designated Expert Review for<br> future allocations. Are the instructions to the Designated Expert clear?<br> Please include suggestions of designated experts, if appropriate.<br><br>[TBD] <br><br>[1]: https://www.ietf.org/about/groups/iesg/<br>[2]: https://www.rfc-editor.org/rfc/rfc4858.html<br>[3]: https://www.rfc-editor.org/rfc/rfc7942.html<br>[4]: https://wiki.ietf.org/group/ops/yang-review-tools<br>[5]: https://www.rfc-editor.org/rfc/rfc8342.html<br>[6]: https://wiki.ietf.org/group/iesg/ExpertTopics<br>[7]: https://www.rfc-editor.org/info/bcp79<br>[8]: https://www.ietf.org/tools/idnits/<br>[9]: https://www.rfc-editor.org/rfc/rfc3967.html<br>[10]: https://www.rfc-editor.org/info/bcp97<br>[11]: https://www.rfc-editor.org/rfc/rfc8126.html<br>[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5<br>[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1<br>[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2<br>[15]: https://authors.ietf.org/en/content-guidelines-overview<br>[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/<br>[17]: https://datatracker.ietf.org/doc/downref/<br><br>changed_protocol_writeupietfidrSusan HaresactiveidexistswriteupwSegment Routing Segment Types Extensions for BGP SR Policy9817502024-03-19T16:01:56-07002024-03-19T16:01:56-0700Susan HaresIETF WG state changed to <b>WG Consensus: Waiting for Write-Up</b> from In WG Last Callchanged_stateietfidrSusan HaresactiveidexistswriteupwAdvertising Segment Routing Policies in BGP9817072024-03-19T14:47:11-07002024-03-19T14:47:11-0700Susan HaresIETF WG state changed to <b>WG Consensus: Waiting for Write-Up</b> from In WG Last Callchanged_stateietfidrSusan HaresactiveidexistswriteupwVPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-49814772024-03-19T00:09:03-07002024-03-19T00:09:03-0700Wei WangNew version available: <b>draft-ietf-idr-vpn-prefix-orf-06.txt</b>new_revisionietfidrSusan Haresactiveidexistswg-doc This draft defines a new Outbound Route Filter (ORF) type, called the
VPN Prefix ORF. The described VPN Prefix ORF mechanism is applicable
when the VPN routes from different VRFs are exchanged via one shared
BGP session (e.g., routers in a single-domain connect via Route
Reflector).
06VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-49814762024-03-19T00:09:03-07002024-03-19T00:09:03-0700(System)New version approvednew_submissionietfidrSusan Haresactiveidexistswg-docVPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-49814752024-03-19T00:08:31-07002024-03-19T00:08:31-0700(System)Request for posting confirmation emailed to previous authors: Aijun Wang <wangaj3@chinatelecom.cn>, Gyan Mishra <gyan.s.mishra@verizon.com>, Haibo Wang <rainsword.wang@huawei.com>, Jie Dong <jie.dong@huawei.com>, Shunwan Zhuang <zhuangshunwan@huawei.com>, Wei Wang <weiwang94@foxmail.com>new_submissionietfidrSusan Haresactiveidexistswg-docVPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-49814742024-03-19T00:08:30-07002024-03-19T00:08:30-0700Wei WangUploaded new revisionnew_submissionietfidrSusan Haresactiveidexistswg-docBGP-LS with Multi-topology for Segment Routing based Virtual Transport Networks9805602024-03-18T00:05:13-07002024-03-18T00:05:13-0700(System)Document has expiredexpired_documentietfidrexpiredidexistswg-docBGP Classful Transport Planes9803802024-03-17T21:12:08-07002024-03-17T21:12:08-0700Kaliraj VairavakkalaiNew version available: <b>draft-ietf-idr-bgp-ct-30.txt</b>new_revisionietfidrSusan Haresactiveidexistswriteupw This document specifies a mechanism referred to as "Intent Driven
Service Mapping". The mechanism uses BGP to express intent based
association of overlay routes with underlay routes having specific
Traffic Engineering (TE) characteristics satisfying a certain Service
Level Agreement (SLA). This is achieved by defining new constructs
to group underlay routes with sufficiently similar TE characteristics
into identifiable classes (called "Transport Classes"), that overlay
routes use as an ordered set to resolve reachability (Resolution
Schemes) towards service endpoints. These constructs can be used,
for example, to realize the "IETF Network Slice" defined in TEAS
Network Slices framework.
Additionally, this document specifies protocol procedures for BGP
that enable dissemination of service mapping information in a network
that may span multiple cooperating administrative domains. These
domains may be administered either by the same provider or by closely
coordinating providers. A new BGP address family that leverages RFC
4364 procedures and follows RFC 8277 NLRI encoding is defined to
advertise underlay routes with its identified class. This new
address family is called "BGP Classful Transport", a.k.a., BGP CT.
30BGP Classful Transport Planes9803792024-03-17T21:12:08-07002024-03-17T21:12:08-0700Kaliraj VairavakkalaiNew version accepted (logged-in submitter: Kaliraj Vairavakkalai)new_submissionietfidrSusan HaresactiveidexistswriteupwBGP Classful Transport Planes9803782024-03-17T21:12:07-07002024-03-17T21:12:07-0700Kaliraj VairavakkalaiUploaded new revisionnew_submissionietfidrSusan HaresactiveidexistswriteupwSR Policies Extensions for NRP in BGP-LS9802502024-03-17T17:57:48-07002024-03-17T17:57:48-0700Ran ChenNew version available: <b>draft-chen-idr-bgp-ls-sr-policy-nrp-06.txt</b>new_revisionnoneactiveidexists This document defines a new TLV which enable the headend to report
the configuration and the states of SR policies carrying NRP
information by using BGP-LS.
06SR Policies Extensions for NRP in BGP-LS9802492024-03-17T17:57:47-07002024-03-17T17:57:47-0700Ran ChenNew version accepted (logged-in submitter: Ran Chen)new_submissionnoneactiveidexistsSR Policies Extensions for NRP in BGP-LS9802472024-03-17T17:57:46-07002024-03-17T17:57:46-0700Ran ChenUploaded new revisionnew_submissionnoneactiveidexistsBGP Classful Transport Planes9801482024-03-17T16:19:37-07002024-03-17T16:19:37-0700Kaliraj VairavakkalaiNew version available: <b>draft-ietf-idr-bgp-ct-29.txt</b>new_revisionietfidrSusan Haresactiveidexistswriteupw This document specifies a mechanism referred to as "Intent Driven
Service Mapping". The mechanism uses BGP to express intent based
association of overlay routes with underlay routes having specific
Traffic Engineering (TE) characteristics satisfying a certain Service
Level Agreement (SLA). This is achieved by defining new constructs
to group underlay routes with sufficiently similar TE characteristics
into identifiable classes (called "Transport Classes"), that overlay
routes use as an ordered set to resolve reachability (Resolution
Schemes) towards service endpoints. These constructs can be used,
for example, to realize the "IETF Network Slice" defined in TEAS
Network Slices framework.
Additionally, this document specifies protocol procedures for BGP
that enable dissemination of service mapping information in a network
that may span multiple cooperating administrative domains. These
domains may be administered either by the same provider or by closely
coordinating providers. A new BGP address family that leverages RFC
4364 procedures and follows RFC 8277 NLRI encoding is defined to
advertise underlay routes with its identified class. This new
address family is called "BGP Classful Transport", a.k.a., BGP CT.
30BGP Classful Transport Planes9801472024-03-17T16:19:36-07002024-03-17T16:19:36-0700Kaliraj VairavakkalaiNew version accepted (logged-in submitter: Kaliraj Vairavakkalai)new_submissionietfidrSusan HaresactiveidexistswriteupwBGP Classful Transport Planes9801462024-03-17T16:19:36-07002024-03-17T16:19:36-0700Kaliraj VairavakkalaiUploaded new revisionnew_submissionietfidrSusan HaresactiveidexistswriteupwBGP Color-Aware Routing (CAR)9801392024-03-17T16:15:03-07002024-03-17T16:15:03-0700Susan Hares# Document Shepherd Write-Up for Group Documents<br><br>*This version is dated 4 July 2022. [RFC4858] <br><br>Action items - prior to publishing <br> 1) Need Jim Uttaro to give an IPR statement for -06 <br> He gave support without an IPR Statement. <br> 2) publish -07 with editorial changes<br> 3) Check on responses from PCE, BESS, Spring <br> 4) Early Review from IANA review of -06<br> 5) OPS-DIR Early Review [-06]<br> 6) RTG-AD check on normative/informative list. <br> 7) final NITS check<br> 8) Update of shepherd with issues from 1-7<br> 9) Update of the implementation report <br><br>## Document History<br><br>1. Does the working group (WG) consensus represent the strong concurrence of a<br> few individuals, with others being silent, or did it reach broad agreement?<br><br>This document history is in reverse order for ease of access. <br><br>The CAR progression after adoption is tracked on both the IDR Wiki<br>and the IDR WG Github <br>wiki: https://wiki.ietf.org/e/en/group/idr/CAR-WGLC)<br>github: https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-car/issues<br><br>Status<br>=====<br>Post 2nd WG LC Shepherd's review of -06.txt<br>[Shepherd report on Editorial issues: <br>https://mailarchive.ietf.org/arch/msg/idr/de9x2kpB8bI-kojYlYOozKNArsk/<br><br>Shepherd Report as issue lists (github)<br>G1- Should Fix issues: (16) [(github issue 19)](https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-car/issues/19): status: fixes agreed upon, fixing in -07 <br>G2- IANA Issues: Github issue 20](https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-car/issues/20), status agreed upon, fixing in -07, <br> Early IANA review requested (3/12)<br>G3- Editorial Nits in Main text (37): Github issues 21-24 - fixing in -07 <br>[github 21](https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-car/issues/21), <br>[github 22](https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-car/issues/22), <br>[github 23](https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-car/issues/23), <br>[github 24](https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-car/issues/24) <br>G4- Editorial Nits in Appendices: Github issue 25<br>[github 25](https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-car/issues/25) -fixing in -07 <br><br>-------<br>2nd WG LC: 2/16/2024 to 3/1/2024<br> Initial call: <br> https://mailarchive.ietf.org/arch/msg/idr/vnaLLq3MUuiONqfjFkpIPl9Q-Zs/<br> Status: Consensus on publication of draft-ietf-idr-bgp-car-06 <br> https://mailarchive.ietf.org/arch/msg/idr/0z4B2QfVGmmS7EI6IFjfHccd8AY/<br><br>Directorate reviews before 2nd WG LC <br> RTG-DIR (by Mike McBride): status: has nits [draft-ietf-idr-bgp-car-05] <br> https://datatracker.ietf.org/doc/review-ietf-idr-bgp-car-05-rtgdir-early-mcbride-2024-01-04/<br> OPS-DIR (missing) <br> SEC-DIR (by Yoav Nir): status: has nits [draft-ietf-idr-bgp-car-05] <br> https://datatracker.ietf.org/doc/review-ietf-idr-bgp-car-05-secdir-early-nir-2023-12-19/ <br> TSV-DIR (by Brian Trammel): status: On the right track <br> https://datatracker.ietf.org/doc/review-ietf-idr-bgp-car-05-tsvart-early-trammell-2024-01-16/ <br>-----<br>Post WG LC - Interim discussion on 9/25 <br>(https://mailarchive.ietf.org/arch/msg/idr/2mPRIH98LYjrnZ1t4USVij_qzKs/) <br> <br>------<br>1st WG LC <br>version: draft-ietf-idr-bgp-car-02 <br>Email call: <br>https://mailarchive.ietf.org/arch/msg/idr/_6wv8MYHgMESkH3ZjVlzn14KYy8/<br>result: Non-consensus <br>(https://mailarchive.ietf.org/arch/msg/idr/2mPRIH98LYjrnZ1t4USVij_qzKs/)<br><br>## Shepherd Report for 1st WG LC on wiki: <br>list of issues: [car-wg-lc-track-v7.pdf](/idr/car-wg-lc-track-v7.pdf)<br>Shepherd's report on issues: [car-shepherd-report](/idr/idr-shepherd-car-wglc-q1-issues-v3.pdf)<br><br>-----<br>Adoption call: 7/6/2022 to 7/27/2022 in 3 mail threads.<br><br>Part 1 of CAR/CT Adoption call (7/6 to 7/27):Informational Questions<br>https://mailarchive.ietf.org/arch/msg/idr/FhoK04HsSy9tR7ioV7AD0Vv6Ir4/<br><br>Part 2 of CAR/CT Adoption call (7/6 to 7/27): Adoption call<br>https://mailarchive.ietf.org/arch/msg/idr/AP_ClbZgpkX6CNy7TaZiU8SMD5w/<br><br>Part 3 of CAR/CT Adoption call (7/14 to 7/27) - Please note that Part 3 has a specific format for posting.<br>https://mailarchive.ietf.org/arch/msg/idr/fTFYwF54WRHcj7PDt2t7sOQg6vo/<br><br>The shepherd's write-up on this topic is available on the IDR wiki<br>https://trac.ietf.org/trac/idr/wiki/CAR-CT%20Adoption%20call%20(7/6/2022%20to%207/27/2022)<br><br>--------------------<br>This adoption call was preceded by the following:<br>Presentations from IETF-108 to IETF-113<br>IDR interim on January 24, 2022<br>(https://datatracker.ietf.org/meeting/interim-2022-idr-02/session/idr)<br><br>Email Discussion before IETF-113<br>https://mailarchive.ietf.org/arch/msg/idr/e69NRd9i2aG0WUxFkShEfQHZsHo/<br><br>Note: The IDR chairs agree with the summary of Jeff Haas (IDR Co-chair) <br>posted on March 21, 2022 - that for route resolution and route origination/propagation, <br>BGP-CAR and BGP-CT are functionally identical, but operationally different.<br>-----<br>Dependencies on Spring:<br>a) Link to Spring Individual drafts in Spring adoption queue <br> Link to draft-hr-spring-intentaware-routing-using-color-03 <br> for requirements of Intent/Color aware routing. <br> Note: Since these requirements were not a WG draft, <br> this caused CAR to have only theoretical scaling results.<br> Shepherd allowed the scaling results to be theoretical without proof in CT.<br><br> Link to Spring Individual Internet Drafts in informative text: <br> draft-agrawal-spring-srv6-mpls-interworking-13. <br> <br> Spring chairs have been advised about these two drafts. <br><br>b) MPLS draft that is dead [draft-ietf-mpls-seamless-mpls-07] <br> status is: IESG Dead. <br>--------<br>c. Dependencies with PCE<br>Dhruv Dhody reviewed the interactions with PCE drafts.<br>He sent comments to the CAR authors. [need the link] <br><br>d. Dependencies with BESS:<br> BESS chairs were queried about reviewing the CAR and CT drafts.<br> No direct information was received.<br>----------<br>## Directorate Reviews: (tracked by Datatracker) with comments from shepherd<br>RTG-DIR reviews:<br>Early Review of draft-ietf-idr-bgp-car-02 (Ben Niven) - Issues, needs introduction <br>(https://mailarchive.ietf.org/arch/msg/idr/0X_q_e09ejtb0NZQ25smUrklwmQ/)<br>Review of draft-ietf-idr-bgp-bgp-car-05 (Mike McBride) - status: has nits, <br>(IDR Shepherd is worried about the depth of type-1/type-2 review in this shepherd review. <br> The shepherd may have considered it, but no comments were mentioned.) <br> https://datatracker.ietf.org/doc/review-ietf-idr-bgp-car-05-rtgdir-early-mcbride-2024-01-04/<br><br>OPS-DIR reviews:<br>Early Review of draft-ietf-idr-bgp-car-02 (Yingzhen Qu) - status: has issues <br>https://datatracker.ietf.org/doc/review-ietf-idr-bgp-car-02-opsdir-early-qu-2023-08-22/)<br>Missing Early review of draft-ietf-idr-bgp-car-05 - [pending] <br><br>SEC-DIR reviews: <br>Early review of draft-ietf-idr-bgp-car-05 (Yoav Nir) - status: has nits <br>https://datatracker.ietf.org/doc/review-ietf-idr-bgp-car-05-secdir-early-nir-2023-12-19/<br><br>2. Was there controversy about particular points, or were there decisions where<br> the consensus was particularly rough?<br><br>Rough Adoption decision:<br>The IDR chairs agree with Jeff Haas's (IDR Co-chair) summary posted on March<br>21, 2022, that for route resolution and route origination/propagation, BGP-CAR<br>and BGP-CT are functionally identical but operationally different.<br><br>IDR WG could not come to a consensus on CAR vs. CT. IDR Chairs elected to adopt<br>both CAR and CT drafts as experimental drafts. Experience in the market<br>place will help determine which is better operationally.<br><br>Rough 1st WG LC of CAR/CT: The IDR WG LC for CAR and CT found the<br>editors/authors/contributors of CT commenting on the CAR draft (Just as CAR<br>authors commented on CT draft). In some ways, this lively debate helped find<br>problems in the specifications.<br><br>2nd WG LC of CAR/CT: This WG LC did not have a lot of<br>CAR/CT editor discussions because the IDR Shepherding Chair had<br>a private discussion between editors prior to the 2nd WG LC.<br><br>3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If<br> so, please summarize the areas of conflict in separate email messages to the<br> responsible Area Director. (It should be in a separate email because this<br> questionnaire is publicly available.)<br><br>Andrew mentioned he received feedback that there would be discomfort<br>if the CAR and CT do not progress to the Experimental simultaneously.<br>See Andrew Alston for additional details.<br><br>4. For protocol documents, are there existing implementations of the contents of<br> the document? Have a significant number of potential implementers indicated<br> plans to implement? Are any existing implementations reported somewhere,<br> either in the document itself (as [RFC 7942][3] recommends) or elsewhere<br> (where)?<br><br> 2 WG LC: Implementation claimed by cisco, arccus, and freertr. <br> Implementation report: <br> https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-bgp-car<br><br><br>5. Do the contents of this document closely interact with technologies in other<br> IETF working groups or external organizations, and would it therefore benefit<br> from their review? Have those reviews occurred? If yes, describe which<br> reviews took place.<br><br> Reviews requested from PCE, Spring, and BESS before 2nd WG LC.<br> Received reviews from PCE: [need link]<br> Received feedback from Spring chairs (Alvaro Retana)<br> The following drafts were in the option queue:<br> draft-hr-spring-intentaware-routing-using-color<br> draft-agrawal-spring-srv6-mpls-interworking-13 (validate again) <br><br> Nothing was received from BESS.<br> RTG-DIR reviews: 2 early reviews - (-05) has nits, (-02) has issues <br> OPS-DIR reviews: 1 early reviews - (-02) has issues, [pending for -06] <br> SEC-DIR reviews: 1 early reviews - (-05) has nits<br> TSV-DIR review: 1 early review - (-05) on the Right Track <br> review: IANA early review of draft-ietf-idr-bgp-car-06 (3/12 request) <br><br>6. Describe how the document meets any required formal expert review criteria,<br> such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.<br><br> No requirement for formal review (MIB, Yang, Media type, and URI)<br> A yang module for CT will be added to the list of Yang modules to create for<br> BGP.<br><br>7. If the document contains a YANG module, has the final version of the module<br> been checked with any of the [recommended validation tools][4] for syntax and<br> formatting validation? If there are any resulting errors or warnings, what is<br> the justification for not fixing them at this time? Does the YANG module<br> comply with the Network Management Datastore Architecture (NMDA) as specified<br> in [RFC 8342][5]?<br><br> No Yang in the document<br><br>8. Describe reviews and automated checks performed to validate sections of the<br> final version of the document written in a formal language, such as XML code,<br> BNF rules, MIB definitions, CBOR's CDDL, etc.<br> No automated checking<br><br>## Document Shepherd Checks<br><br>9. Based on the shepherd's review of the document, is it their opinion that this<br> document is needed, clearly written, complete, correctly designed, and ready<br> to be handed off to the responsible Area Director?<br><br> Checks completed:<br> 1) Pre-Adoption by Jeff Haas and discussion among chairs<br> 2) Careful Adoption review resulted in a list of issues that needed to be<br> resolved:<br> (https://wiki.ietf.org/group/idr/CAR-CTAdoption)<br> 3) Adoption call issues added to github for draft-ietf-idr-bgp-car-02 <br> https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-car<br><br> 4) 1st WG LC -<br> Prior to 1st WG LC: Shepherd verified that issues were addressed<br> and early Early Directorate reviews requested,<br> 1st WG LC: Shepherd report written<br> (see https://wiki.ietf.org/group/idr/CAR-WGLC and<br> https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-car/issues<br> Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff Haas.<br><br> 5) 2nd WG LC<br> Prior to 2nd WG LC:<br> a) Shepherd verified that issues raised in 1st WG LC were addressed.<br> b) Review provided by IDR Chair team: Jie Dong, Keyur Patel, and Jeff<br> Haas. <br> c) IDR Shepherd resoloved Technical issues - via email and meetings<br> d) Early reviews requested for -05 (RTG-DIR, OPS-DIR, SEC-DIR, and TSV-DIR)<br> open reviews: resolution of OPS-DIR. <br> d) Meeting with CAR and CT editor teams during 2nd WGLC<br> e) two interims in 2024 - January 29 and February 26 - review status<br> 6) Post WG LC<br> a) Shepherd reports with editorial nits <br> b) Shepherd report loaded into github as issues <br> c) Review issues with document editors - awaiting -07 version to check resolution. <br> d) IANA review of -06 requested. [pending]<br> e) Requested the OPS-DIR review of current version (-06 or -07) by 3/28. <br> <br> 7) Current pending status for Shepherd's checks <br> a) Response from IANA review of -06<br> b) Response from OPS-DIR resolution check<br> c) final NITS check<br><br><br>10. Several IETF Areas have assembled [lists of common issues that their<br> reviewers encounter][6]. For which areas have such issues been identified<br> and addressed? For which does this still need to happen in subsequent<br> reviews?<br> <br> Early review from TSV confirmed the Color/Intent is on the right track. <br> Early review from SEC-DIR did not find problems. <br> Missing review from OPS-DIR on -05 or -06 version <br><br>11. What type of RFC publication is being requested on the IETF stream ([Best<br> Current Practice][12], [Proposed Standard, Internet Standard][13],<br> [Informational, Experimental or Historic][14])? Why is this the proper type<br> of RFC? Do all Datatracker state attributes correctly reflect this intent?<br><br> Experimental draft. Why? IDR cannot settle on a single solution for<br> Intent-based (Color) routing. The top 2 solutions are forwarded as<br> experimental drafts to allow operational deployment to give feedback.<br><br>12. Have reasonable efforts been made to remind all authors of the intellectual<br> property rights (IPR) disclosure obligations described in [BCP 79][7]? To<br> the best of your knowledge, have all required disclosures been filed? If<br> not, explain why. If yes, summarize any relevant discussion, including links<br> to publicly-available messages when applicable.<br><br>Editors: <br>Dhananjaya Rao (dhrao@cisco.com)<br>1st WG LC <br>https://mailarchive.ietf.org/arch/msg/idr/a7B2ewERryNrT3EtO2k2hpwL_Xk/<br>2nd WG LC <br>https://mailarchive.ietf.org/arch/msg/idr/t9SNNGKovgouzX9JflxrF-S9JA4/<br><br>Swadesh Agrawal <br>swaagraw@cisco.com<br>1st WG LC: <br>https://mailarchive.ietf.org/arch/msg/idr/nrnVIHYX7W1zwoZ4kIK9cMYJeQE/<br>2nd WG LC: <br>https://mailarchive.ietf.org/arch/msg/idr/Yf5t6UJyZvpUln9pt3L_vezA1_o/<br><br>Authors: <br>Clarence Filsfils (cfilsfil)<br>2nd WG LC: <br>https://mailarchive.ietf.org/arch/msg/idr/pPwHlbefWf-41sd-CUCwABfncjs/<br><br>Bruno Descraene (bruno.decraene@orange.com) <br>1st WG LC: <br>https://mailarchive.ietf.org/arch/msg/idr/OJQE8kx7idm-i5S3KPSDBBZID6w/<br>2nd WG LC: <br>https://mailarchive.ietf.org/arch/msg/idr/AhkEXE1qIZKd_g6JHLUpwq-0B10/<br><br>Luay Jalil (luay.jalil@verizon.com) <br>1st WG LC: <br>https://mailarchive.ietf.org/arch/msg/idr/zgaHaWz0-Zh7hDJ-bG7I4iu0heI/<br>2nd WG LC:<br>https://mailarchive.ietf.org/arch/msg/idr/y-7xBJabNZfZIysh5dRd_8ZH93Y/<br><br>Yuanchao Su (yitai.syc@alibaba-inc.com)<br>2nd WG LC:<br>https://mailarchive.ietf.org/arch/msg/idr/JuoFvhFypSH7foZW9S3nq0haxMo/<br><br>Jim Uttaro (jul738@att.com) <br>1st WG LC:<br>https://mailarchive.ietf.org/arch/msg/idr/_E8wLXIei3p18CgrZe1dR1dYOdU/<br>2nd WG LC: [no IPR statement in WG LC 2] <br>Support: https://mailarchive.ietf.org/arch/msg/idr/UMMdvcGZo-YMLhL_WgsoyYyNKTA/<br>https://mailarchive.ietf.org/arch/msg/idr/d7RGLGREzL8cWEXG3kt4zcH9WbQ/<br><br>Jim Guichard (james.n.guichard@futurewei.com) <br>1st WG LC: <br>https://mailarchive.ietf.org/arch/msg/idr/uQvAeNYnU4Tl_V8Jgr7V6iT0szs/<br>2nd WG LC: <br>https://mailarchive.ietf.org/arch/msg/idr/0xY2q4n0N6d18m3h-sUPtVL5w8Q/<br><br>Ketan Talaulikar (ketant.ietf@gmail.com) <br>1st WG LC: <br>https://mailarchive.ietf.org/arch/msg/idr/vH-nM56JLumbAB6JyiMJVhVVXp8/<br>2nd WG LC: <br>https://mailarchive.ietf.org/arch/msg/idr/db6ibKFpH3xlU9ZCNw5MrvHennE/<br><br>Keyur Patel - keyur@arrcus.com <br>1st WG LC: <br>https://mailarchive.ietf.org/arch/msg/idr/zH7yZ8JY90aizrvt_UbDiW0MPb4/<br>2nd WG LC <br>https://mailarchive.ietf.org/arch/msg/idr/db6ibKFpH3xlU9ZCNw5MrvHennE/<br><br>Haibo Wang<br>2nd WG LC:<br>https://mailarchive.ietf.org/arch/msg/idr/Q-mu1tej5zbt5qUVHtAs7Sq5gCw/<br><br>Jie Dong<br>2nd WGLC: <br>https://mailarchive.ietf.org/arch/msg/idr/w37WDDhusHqheD_X7e3de-pAFE8/<br><br>Contributors: <br>Dirk Steinberg (Dirk@lapishills.com)<br>2nd WG LC: <br>https://mailarchive.ietf.org/arch/msg/idr/YWnHAeBBpXdJs6F6q_F2cG9pPZA/<br><br>Israel Means (im8327@att.com) <br>2nd WG LC: <br>https://mailarchive.ietf.org/arch/msg/idr/AF9DV51BLMOirSaCRUl876e571I/<br><br>Reza Rokui (rrokui@ciena.com)<br>2nd WG LC:<br>https://mailarchive.ietf.org/arch/msg/idr/PXo0-fRGx9ibcZHfFypVLizqZx8/<br><br>13. Has each author, editor, and contributor shown their willingness to be<br> listed as such? If the total number of authors and editors on the front page<br> is greater than five, please provide a justification.<br><br>Total number of editors: 2<br>Total number of authors: 10 (back page) <br>Total number of contributors: 3 [back page] <br><br>14. Document any remaining I-D nits in this document. Simply running the [idnits<br> tool][8] is not enough; please review the ["Content Guidelines" on<br> authors.ietf.org][15]. (Also note that the current idnits tool generates<br> some incorrect warnings; a rewrite is underway.)<br><br>[NITS - awaits the -07 version of the draft] <br><br>15. Should any informative references be normative or vice-versa? See the [IESG<br> Statement on Normative and Informative References][16].<br><br> IDR Chairs team has looked at normative versus non-normative. <br> [Pending] Request RTG-AD for IDR take a look at normative. <br><br>16. List any normative references that are not freely available to anyone. Did<br> the community have sufficient access to review any such normative<br> references?<br><br> All References are RFCs or Internet Drafts. <br><br>17. Are there any normative downward references (see [RFC 3967][9] and [BCP<br> 97][10]) that are not already listed in the [DOWNREF registry][17]? If so,<br> list them.<br><br> [No] <br><br>18. Are there normative references to documents that are not ready to be<br> submitted to the IESG for publication or are otherwise in an unclear state?<br> If so, what is the plan for their completion?<br> <br> [No] <br><br>19. Will the publication of this document change the status of any existing RFCs? If<br> so, does the Datatracker metadata correctly reflect this and are those RFCs<br> listed on the title page, in the abstract, and discussed in the<br> introduction? If not, explain why and point to the part of the document<br> where the relationship of this document to these other RFCs is discussed.<br><br> This document does not change any other document. <br><br>20. Describe the document shepherd's review of the IANA considerations section,<br> especially with regard to its consistency with the body of the document.<br> Confirm that all aspects of the document requiring IANA assignments are<br> associated with the appropriate reservations in IANA registries. Confirm<br> that any referenced IANA registries have been clearly identified. Confirm<br> that each newly created IANA registry specifies its initial contents,<br> allocations procedures, and a reasonable name (see [RFC 8126][11]).<br><br> Review the IANA considerations sections with authors and [RFC8126]. <br> Requested early IANA Review of section. <br><br>21. List any new IANA registries that require Designated Expert Review for<br> future allocations. Are the instructions to the Designated Expert clear?<br> Please include suggestions of designated experts, if appropriate.<br><br> Two registries are designated expert review: <br> a. BGP CAR NLRI Types Registry<br> b. BGP CAR NLRI TLV Registry<br><br> As a shepherd, I felt the review criteria in section 10.3 <br> was not adequate. After a discussion with the authors, I decided<br> to ask for an early IANA Review. I will also talk to the <br> IANA people at IETF-119. <br><br>[1]: https://www.ietf.org/about/groups/iesg/<br>[2]: https://www.rfc-editor.org/rfc/rfc4858.html<br>[3]: https://www.rfc-editor.org/rfc/rfc7942.html<br>[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools<br>[5]: https://www.rfc-editor.org/rfc/rfc8342.html<br>[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics<br>[7]: https://www.rfc-editor.org/info/bcp79<br>[8]: https://www.ietf.org/tools/idnits/<br>[9]: https://www.rfc-editor.org/rfc/rfc3967.html<br>[10]: https://www.rfc-editor.org/info/bcp97<br>[11]: https://www.rfc-editor.org/rfc/rfc8126.html<br>[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5<br>[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1<br>[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2<br>[15]: https://authors.ietf.org/en/content-guidelines-overview<br>[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/<br>[17]: https://datatracker.ietf.org/doc/downref/<br><br>changed_protocol_writeupietfidrSusan HaresactiveidexistswriteupwAdvertising SID Algorithm Information in BGP9799682024-03-17T06:03:19-07002024-03-17T06:03:19-0700Yao LiuNew version available: <b>draft-peng-idr-segment-routing-te-policy-attr-09.txt</b>new_revisionietfidractiveidexistswg-cand This document defines new Segment Types and proposes extensions for
BGP to provide algorithm information for SR-MPLS Adjacency-SIDs when
delivering SR Policy via BGP.
09Advertising SID Algorithm Information in BGP9799672024-03-17T06:03:18-07002024-03-17T06:03:18-0700Yao LiuNew version accepted (logged-in submitter: Yao Liu)new_submissionietfidractiveidexistswg-candAdvertising SID Algorithm Information in BGP9799662024-03-17T06:03:17-07002024-03-17T06:03:17-0700Yao LiuUploaded new revisionnew_submissionietfidractiveidexistswg-cand