Inter-Domain Routing
charter-ietf-idr-06

[Ballot comment]
Thank you for addressing my prior BLOCK feedback with 05-03.

== prior COMMENT

At the highest level, given the tremendous document load in the IDR WG already, is this broad scope appropriate?  Will it accelerate the publication of documents?

(1) “The primary objective (and priority) of the Inter-Domain Routing (IDR) Working Group (WG) is to develop and maintain BGP as the standard inter-domain routing protocol deployed for IPv4 and IPv6 routing over the Internet.”

I applaud the new charter text mentioning priorities given the document load.  I wasn’t able to reconcile how all of the subsequent scoping text met this notion of setting priorities.

Changed charter milestone "Prefix and ASpath ORF draft to IESG as a Proposed Standard", set description to "Prefix ORF draft to IESG as a Proposed Standard", added draft-ietf-idr-bgp-prefix-orf to milestone

Changed charter milestone "Submit Outbound Route Filter, Prefix and ASpath ORF draft to IESG as a Proposed Standard", set description to "Submit Outbound Route Filter draft to IESG as a Proposed Standard", added draft-ietf-idr-route-filter to milestone

[Ballot comment]
Hi all,

Thank you for the discussion and various inputs provided so far [1].

The changes made so far in [2] are an enhancement. I aprpeciate that some of the items in [1] may require longer cycles that this rechartering round.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/idr/hNzUex4Jv0788HMomKdYjWsnfss/

[2] https://author-tools.ietf.org/iddiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-idr%2Fwithmilestones-05-00.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-idr%2Fwithmilestones-05-02.txt&difftype=--hwdiff

[Ballot comment]
The charter is lengthy and complex. however, given that the IDR WG is a highly active working group operating across a broad set of solutions, extensions and deployment use cases, i think it is appropriate and complete.

[Ballot comment]
I concur with the scope comments from Med and Roman (as well as others).  That is a very large body of work stated in the charter.

The charter is well written and understandable, and the effort in milestone management is very impressive.

[Ballot block]
(1) “As listed in the work areas, the WG may take up work on BGP extensions to support the work happening in other WGs following consultation with the relevant WG Chairs and Responsible ADs. The WG shall coordinate closely with the originating WG(s) that is responsible for the overall framework, architecture, and requirements. Progression of such work in IDR WG shall follow the maturity (specifically the adoption and WGLC milestones) of the corresponding base work in those WGs. Relevant WGs include, but are not limited to, SPRING, TEAS, CATS, SAVNET, and, in the context of BGP-LS, LSR.”

Is this describing scope or procedures?  It is already the case that any body of work that’s in scope for WG1 but started in WG2, could move to WG1 assuming there was consensus in WG1 and WG2.  Is this text saying that the chartered scope would dynamically for WG1 expand if such document shift occurred?

(2) “The IDR WG is expected to review BGP-related work in other WGs that is specifically impacting core BGP protocol aspects and provide timely feedback during (but not limited to) WG adoption and last calls in those respective WGs.”

As a statement on WG scoping, I don’t understand.  Any participant in any WG can review the work of other WGs.  It is unclear what it would mean that there are expectations on a WG (i.e., the text says “The IDR WG is expected to review …”), rather than participants in the IETF, to review BGP document in other WGs.  How would one know those expectations are met?  Since this review has not formal standing beyond the individual doing the reviews, what role does this text play in the charter?

[Ballot comment]
I also share the BLOCK concerns raised by Med Boucadair.

At the highest level, given the tremendous document load in the IDR WG already, is this broad scope appropriate?  Will it accelerate the publication of documents?

(1) “The primary objective (and priority) of the Inter-Domain Routing (IDR) Working Group (WG) is to develop and maintain BGP as the standard inter-domain routing protocol deployed for IPv4 and IPv6 routing over the Internet.”

I applaud the new charter text mentioning priorities given the document load.  I wasn’t able to reconcile how all of the subsequent scoping text met this notion of setting priorities.

(2) “The IDR WG may consider adopting work related to new BGP address families, feature extensions, or work areas not explicitly listed above. However, adoption of such work will require demonstrated interest and sufficient expertise within the WG, and will be subject to a rechartering process (i.e., IDR will not become the WG that automatically adopts any BGP work).”

What’s new here and why is this text needed?  It is not clear what new scoping guidance is being provided.  Any WG could expand their scope subject to re-chartering with demonstrated interest.

(3) “Given the broad use of BGP across various WGs in the IETF, the IDR WG will provide advice and collaborate closely with other WGs developing or relying on BGP extensions and their BGP-related YANG models.”

What’s new here and why is this text needed?  Every WG that is developing a core technology can provide this advisor service without the chartered scope (e.g., questions about QUIC, ask the QUIC WG; questions about TLS, ask the TLS WG).  This advice coming from WG has no formal standing in the standards process beyond that of individual providing feedback.

[Ballot comment]
The charter is long and broad, but I found the current organization relatively easy to digest, particularly after reading it a second time.
In terms of work areas and milestones, I have a suggestion that might help clarify the use of milestones. I note that Med shared a related concern.

CURRENT:

The IDR WG charter lists work areas as opposed to work items, reflecting the ongoing work, the extensible nature of the BGP, and the WG’s operational model. Specific work items and associated documents are captured in the WG milestones, which highlight the most significant and time-sensitive deliverables. Milestones will track progress through WGLC, in line with the WG’s long-standing policy that any protocol specification (excluding YANG modules) must have at least two independent implementations prior to advancing to publication.

PROPOSED:

The IDR WG charter lists work areas as opposed to specific deliverables, reflecting the ongoing work, the extensible nature of the BGP, and the WG’s operational model. Milestones are added for specific deliverables as corresponding documents are adopted by the working group. These are tracked as they progress through WGLC. The working group maintains a long-standing policy that any protocol specification (excluding YANG modules) must have at least two independent implementations prior to advancing to publication.

[Ballot comment]
I support Med's discuss, especially when it comes to organization and priority.

It is a very long charter.  Organizing it into sections and priorities, putting core work first might help drive the work.  If there are long-lived drafts that have not progressed, or perhaps don't have implementations, maybe put those at the bottom of the priority. 

I do sympathize with the challenges of organizing this very busy working group.

[Ballot comment]
Thanks for the effort to recharter such an important working group.

I share many Med Boucadair's BLOCK concerns.

Thanks for indicating the intended publication status (even if the writing is not that crystal clear).

Should there be more details on how to do `the IDR WG will provide advice` and `The IDR WG is expected to review BGP-related work in other WGs` ?

Is there any reason why 6MAN does not appear in `the WG will seek review from V6OPS for IPv6-related extensions` ?

[Ballot block]
Hi all,

Let me first thank the WG and responsible AD for this refresh exercise.

Overall, I do think that the scope is too wide for a single WG.

Please find below some specific items for discussion. Items are listed following the appearance order in the proposed charter:

# Priority

CURRENT:
“The primary objective (and priority) of the Inter-Domain Routing (IDR) Working Group (WG) is to develop and maintain BGP as the standard inter-domain routing protocol deployed for IPv4 and IPv6 routing over the Internet.”

## How this prioritization is materialized in the WG?

## How to make sure multiple minor “adjacent” extensions are not consuming too much WG resources that would prevent the WG from focusing on its core objectives?

# Duplicated functionality and inherited complexity

CURRENT:
  Intent-aware underlay routing, as defined in [RFC9871] and [RFC9832].

## This seems to set in stone that these two redundant and experimental work will be both inherited as such without revisiting/assessing the promises, real differences, need and adoption by operators, etc.

## I do not think that we are making a service by allowing anchors for both CAR/CT solutions.

## A simple fix would be to delete the mention of these two RFCs here.

# Mixing work items and specific specifications

I don’t think it is a good idea to mix a work item and a specific solution.

CURRENT:
* Distribution of routing policies [draft-ietf-idr-rpd].
* Signaling for SD-WAN tunnel discovery [draft-ietf-idr-sdwan-edge-discovery].
* Advertisement of IPv4/IPv6 mappings [draft-ietf-idr-mpbgp-extension-4map6].

For example, draft-ietf-idr-rpd is there for a decade. There is a reason for that work to last for such long period. What if a new document is proposed to address that specific items? Should be discarded because rpd already had a seat?

The same applies for the other two.

# Core protocol operations vs. extensions that are adjacent to routing

CURRENT:
  “the IDR WG will develop and maintain BGP features, extensions, and mechanisms that are largely address-family independent and may be considered core to the protocol’s operation”

## From an OPS perspective, these generic features are important and worth to be prioritized compared to some of the work listed as “adjacent” to routing. Can that be better reflected in the charter?

## s/may be/is

# Conflict with GROW

CURRENT:
  As an exception, the WG may produce Informational documents capturing deployment experience or best practices for BGP features developed within the WG.

This conflicts with GROW per the scope at https://datatracker.ietf.org/wg/grow/about/.

# SIDROPS and GROW

CURRENT:
  GROW (operational practices and monitoring via BMP), and SIDROPS (routing security operations and RPKI)

This does not reflect the exact scope of GROW/SIDROPS as GROW is responsible for “operational global routing system security” or as indicated in the SIDROPS: “Documenting the operational aspects of securing the Internet routing system other than SIDR belongs to GROW WG.”.

[Ballot comment]
# May consider using sub-sections/titles to help structure the charter. This would help easily identify relevant parts in the charter.

# MPLS

It is good that maintenance of RFC 8277 is formally handed to IDR. I checked MPLS Charter and see no blocking issue out there. If not done, maybe make this change more visible by contacting MPLS WG.

# Enhanced version

CURRENT:
* Dissemination of Flow Specification rules [RFC8955] and its enhanced version.

I don’t parse what is meant by enhanced version here.

# Work areas & Milestones

CURRENT:
  The IDR WG charter lists work areas as opposed to work items, reflecting the ongoing work, the extensible nature of the BGP, and the WG’s operational model. Specific work items and  associated documents are captured in the WG milestones, which highlight the most significant and time-sensitive deliverables.

## I don’t quite parse this part as what we do have till here is a very detailed list of specifications. I suspect that you refer to the bullet list right after but the flow seems odd to me.

## The charter says “most significant and time-sensitive deliverables”, but I see the milestones list almost every adopted document.

# Cooperation with OPS WGs

## The charter does already a great job in identifying links with relevant OPS WGs, especially this part:

CURRENT:
“The IDR WG will seek input from GROW and SIDROPS as appropriate, particularly with respect to operational and security considerations during the development of new BGP specifications. Likewise, the WG will seek review from V6OPS for IPv6-related extensions.”

However, given that the new charter also lists BGP/SR extensions in the scope, I think that SRV6OPS is missing from that list as SRv6 Operations (srv6ops) charter has the following:

“IDR WG: Cooperation on SRv6-based BGP extensions, new SRv6-based attributes and encodings, and operational considerations.”

## Thanks to the GROW Tech Advisor, the coordination between GROW/IDR is really great in bridging between the GROW/IDR.

# BGP review

CURRENT:
The IDR WG is expected to review BGP-related work in other WGs that is specifically impacting core BGP protocol aspects and provide timely feedback during (but not limited to) WG adoption and last calls in those respective WGs.

## How this is supposed to work/interact with the newly created BGP Directorate?

## I’m asking this because I noticed that bgp-dir also reviews IDR docs!

Cheers,
Med

Changed charter milestone "Progress base BGP specification (RFC 4271) as Full Standard", set description to "Submit Base BGP specification (RFC 4271) to IESG as an Internet Standard"

Changed charter milestone "WGLC complete for Advertising SR P2MP Policies in BGP as a Proposed Standard", set description to "Complete WGLC for Advertising SR P2MP Policies in BGP as a Proposed Standard"

Changed charter milestone "WGLC complete for BGP Extensions for Routing Policy Distribution as a Proposed Standard", set description to "Complete WGLC for BGP Extensions for Routing Policy Distribution as a Proposed Standard"

Changed charter milestone "WGLC complete for MP-BGP Extension for IPv4/IPv6 Mapping Advertisement as a Proposed Standard", set description to "Complete WGLC for MP-BGP Extension for IPv4/IPv6 Mapping Advertisement as a Proposed Standard"

Changed charter milestone "WGLC complete for BGP for SD-WAN Edge Discovery as a Proposed Standard", set description to "Complete WGLC for BGP for SD-WAN Edge Discovery as a Proposed Standard"

Changed charter milestone "WGLC Complete for BGP Extension for 5G Edge Service Metadata as a Proposed Standard", set description to "Complete WGLC for BGP Extension for 5G Edge Service Metadata as a Proposed Standard"

Changed charter milestone "WGLC Complete for BGP Flow Specification Version 2 - for Basic IP as a Proposed Standard", set description to "Complete WGLC for BGP Flow Specification Version 2 - for Basic IP as a Proposed Standard"

Changed charter milestone "WGLC Complete for BGP BFD Strict-Mode as a Proposed Standard", set description to "Complete WGLC for BGP BFD Strict-Mode as a Proposed Standard"

Changed charter milestone "WGLC Complete for Link-Local Next Hop Capability for BGP as a Proposed Standard", set description to "Complete WGLC for Link-Local Next Hop Capability for BGP as a Proposed Standard"