SRv6 Operations
charter-ietf-srv6ops-01

[Ballot comment]
Would it be helpful to specify the intended status of the milestones or key deliverables?  They all look like they will be Informational, for example.

[Ballot block]
- In “Discussions and presentations aimed at raising awareness of operational artefacts and gathering feedback from the operator community deploying SRv6 are encouraged”, what ARE “operational artefacts”? Can this be written more plainly? (Also, the American spelling is “artifacts”, so unless you’re going to redo the entire thing with UK spelling, you’ll want to make that change if you keep this language.)

- In “Providing recommendations and guidance for various aspects such as IPv6 address planning, block size allocation, and the division of global/local identifiers block (GIB/LIB) for SRv6 SIDs, both with and without SRv6 compression techniques essential for effective network management” I can’t understand what work “essential for effective network management” is doing. Could it be deleted without harm? If not, can you help me understand what you mean?

[Ballot comment]
- Mission bullet list: all gerunds, or no gerunds, whichever you like, but it hurts my eyes to mix them. I.e., please either “be, develop, identify”, or “being, developing, identifying”.

- Should I read anything into the fact that six of the key interacting working groups get “close cooperation” but poor 6man only gets “cooperation” (I guess at arm’s length)?

[Ballot block]
** Per the Scope section:

==[ snip ]==
… provide deployment guidance, address operational issues, identify gaps, and explore potential operational experiments.
==[ snip ]==

What does it mean for a WG to explore potential operational experiments?  What is the artifact of this work?

[Ballot comment]
** Please remove "*Editor's note: We are in the process of trying to convert the BoF group into a WG. This means that the list address is currently incorrect, there are no chairs listed, etc... Please be patient while we turn the administrative crank..."

** Per the Objective section:

==[ snip ]==
Developing operational guidelines to ensure secure, reliable, efficient, and scalable SRv6 network operations.
Identifying and resolving operational challenges encountered during SRv6 deployments.
==[ snip ]==

What is the difference between these two bullets?

[Ballot comment]
For the record, I know it has been brought up already, but I am still concerned with the overlap with SPRING, since SPRING is definitely chartered to do OPS work and already has SRv6 experience and expertise. I know Gunter has suggested a rechartering of SPRING (which I understand is not in the plans?) and the paragraph starting with "The chairs of the SRv6OPS WG will consult with the Area Director ..." was added to address deconflicting topics that would fit both charters, but that still doesn't convince me of the necessity of this wg. However, I am not going to block on those grounds.

[Ballot comment]
# Internet AD comments for charter-ietf-srv6ops-00-03
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

* It's nice that it's scoped to Informational documents, but should we leave
  open the possibility that an operations group might want to produce a BCP?

[Ballot comment]
** Per the Mission section, the following text seem to be repetitive.

==[ snip ]==
* Gathering input from network operators to identify operational issues in SRv6 networks.
* Developing operational guidelines to ensure secure, reliable, efficient, and scalable SRv6 network operations.
* Identifying and resolving operational challenges encountered during SRv6 deployments.
==[ snip ]==

Bullet 1 says the WG will gather input on “operational issues”.  Bullet 3 also says “operational challenges” will be identified.  Is there a difference between operational issues and challenges?

Bullet 2 says that the WG will develop “operational guidelines”.  Is that the same as the “resolving operational challenges” per bullet 3?

** Per the Scope section:

==[ snip ]==
… provide deployment guidance, address operational issues, identify gaps, and explore potential operational experiments.
==[ snip ]==

This text appears to be repetitive to the three bullet points in the previous section except for operational experiments.

What does it mean for a WG to conduct operational experiments?  What is the artifact of this work?  The current charter text says only information documents will be published.

** Per the Scope section:
==[ snip ]==
Operational Issues and Requirements: Addressing IPv6 address planning for SRv6 Segment Identifiers (SIDs), protection, inter-domain, and interworking with other technologies. The requirements may not be published as RFCs but may be maintained in draft form or in a collaborative Working Group space.
==[ snip ]==

Who is the WG publishing requirements for?  Requirements are not mentioned in the Mission section.  I also don’t see any mention of them in the deliverables.

(Editorial) For clarity, I recommend rewording the second sentence to read: “The WG may choose not to publish requirements as an RFC, but maintain them in a draft form or in a collaborative WG space.”

** Per the Key Deliverables section:

==[ snip ]==
Documenting SRv6 deployment experiences, including different deployment scenarios (metro, core, and enterprise networks), scalability, and inter-domain implementations.
==[ snip ]==

The above bullet point seems to be documenting deployment experience.  Is that the same as the “operational issues” and “deployment scenarios” in the Scope section and “gathering input from network operators” in the Mission section?  I ask because in those two other sections, the context was to identify operational issues.  The text here seems to be about documenting operations regardless of whether there are issues.

** Please provide formal milestones.

[Ballot comment]
Thanks for creating this OPS WG, it can only help to deploy even more IETF technologies.

Some quick comments in order to improve the charter itself.

The use of "Mission" seems a little too military, can we simply say "objective" or "charter" ?

`deploying and managing Segment Routing over IPv6 (SRv6) networks` is a little redundant/repetitive with the first statement `The Segment Routing (SR) instantiation on the IPv6 data plane is known as SRv6.` Suggest to keep only the first sentence.

I find `Gathering input from network operators` a little limiting as this OPS WG could also be use to exchange tips & tricks among operators, i.e., acting as a forum.

` The chairs of the SRv6OPS WG will consult with the Area Director (AD)` which AD ? The SRv6OPS AD ? I am not even sure whether this step is required, perhaps a wording such "Operators feedback about under-development should rather be directly be addressed to the relevant WG (e.g., SPRING)."

I have rarely seen `assurance` used alone, suggest using "service assurance".

Unsure whether the very long list of related WG is interesting or useful.

[Ballot comment]
[revised position 15May2024]

[RESOLVED] ISSUE#1:
WAS: "* Recommendations and guidance for IPv6 address planning for SRv6 SID, including SRv6 compression.:
PROBLEM: I am not sure i understand this assertion. May I assume that the text is intending to suggest about recommendations about block size, gib/lib split, etc... This may be more explicit in the charter.
REWRITE: "*Providing recommendations and guidance for various aspects such as IPv6 address planning, block size allocation, and the division of global/local identifiers (gib/lib) for SRv6 SIDs, both with and without SRv6 compression techniques essential for effective network management."

[RESOLVED] ISSUE#2:
WAS: " Discussions and presentations to increase awareness about potential operational issues for feedback from the operator's community are welcome."
PROBLEM: This is very open ended. This may end up as a rathole opportunity for people that do not want to implement SRv6 due to perceived security issues or other perceived operational disasters.
REWRITE: "Discussions and presentations aimed at raising awareness of operational artifacts and gathering feedback from the operator community deploying SRv6 are encouraged."

[RESOLVED] ISSUE#3:
PROBLEM: Network services are updated to operate with SRv6. Such work has been happening in IDR and BESS WG. It would be worthwhile to add these into the collaboration and awareness section.
ADD:
  *BESS WG: Close cooperation on SRv6 based BESS WG protocol extensions, new service transport requirements, and operational considerations.
  *IDR WG: Close cooperation on SRv6 based BGP protocol extensions, new SRv6 based attributes and encodings, and operational considerations.

[RESOLVED] ISSUE#4:
WAS: "* SRv6 deployment experience and best practices, including deployment scenarios (metro, core and enterprise networks), scale-up capability, and inter-domain implementations."
PROBLEM: I believe that the terminology “best practices” is misleading from an SRv6 deployment perspective at this point in time. I suppose, and in fact expect, this WG *not* to produce any BCP. From that perspective the use of “best practices” is misleading. I feel ok with producing informational documents
REWRITE: "The SRv6OPS Working Group (WG) is dedicated to creating informational documents that provide deployment guidance, address operational issues, identify gaps, and explore potential operational experiments."

[RESOLVED] ISSUE#5:
PROBLEM: It can be observed that the second sentence of SPRING's charter says:
  "...SPRING WG serves as a forum to discuss SPRING networks operations..."
FIX: two step approach
(1) Explicitly state that all WG adoption calls are copied to the SPRING mailing list. This will help to capture any overlap quickly.
(2) Update SPRING charter to exclude SRv6 operations from the charter and de-conflict ownership.

[Ballot comment]
[revised position 15May2024]

[RESOLVED] ISSUE#1:
WAS: "* Recommendations and guidance for IPv6 address planning for SRv6 SID, including SRv6 compression.:
PROBLEM: I am not sure i understand this assertion. May I assume that the text is intending to suggest about recommendations about block size, gib/lib split, etc... This may be more explicit in the charter.
REWRITE: "*Providing recommendations and guidance for various aspects such as IPv6 address planning, block size allocation, and the division of global/local identifiers (gib/lib) for SRv6 SIDs, both with and without SRv6 compression techniques essential for effective network management."

[RESOLVED] ISSUE#2:
WAS: " Discussions and presentations to increase awareness about potential operational issues for feedback from the operator's community are welcome."
PROBLEM: This is very open ended. This may end up as a rathole opportunity for people that do not want to implement SRv6 due to perceived security issues or other perceived operational disasters.
REWRITE: "Discussions and presentations aimed at raising awareness of operational artifacts and gathering feedback from the operator community deploying SRv6 are encouraged."

[RESOLVED] ISSUE#3:
PROBLEM: Network services are updated to operate with SRv6. Such work has been happening in IDR and BESS WG. It would be worthwhile to add these into the collaboration and awareness section.
ADD:
  *BESS WG: Close cooperation on SRv6 based BESS WG protocol extensions, new service transport requirements, and operational considerations.
  *IDR WG: Close cooperation on SRv6 based BGP protocol extensions, new SRv6 based attributes and encodings, and operational considerations.

[RESOLVED] ISSUE#4:
WAS: "* SRv6 deployment experience and best practices, including deployment scenarios (metro, core and enterprise networks), scale-up capability, and inter-domain implementations."
PROBLEM: I believe that the terminology “best practices” is misleading from an SRv6 deployment perspective at this point in time. I suppose, and in fact expect, this WG *not* to produce any BCP. From that perspective the use of “best practices” is misleading. I feel ok with producing informational documents
REWRITE: "The SRv6OPS Working Group (WG) is dedicated to creating informational documents that provide deployment guidance, address operational issues, identify gaps, and explore potential operational experiments."

[RESOLVED] ISSUE#5:
PROBLEM: It can be observed that the second sentence of SPRING's charter says:
  "...SPRING WG serves as a forum to discuss SPRING networks operations..."
FIX: two step approach
(1) Explicitly state that all WG adoption calls are copied to the SPRING mailing list. This will help to capture any overlap quickly.
(2) Update SPRING charter to exclude SRv6 operations from the charter and de-conflict ownership.


############################
###start rewrite proposal###
############################

Proposed Charter for SRv6 Operations (SRv6OPS)

The Segment Routing (SR) implementation on the IPv6 data plane is known as SRv6.

**Mission:**
The SRv6OPS Working Group (WG) is dedicated to the operational aspects of deploying and managing Segment Routing over IPv6 (SRv6) networks. Our mission includes:

*Gathering input from network operators to identify operational issues in SRv6 networks.

*Developing best practices and operational guidelines to ensure secure, reliable, efficient, and scalable SRv6 network operations.

*Identifying and resolving operational challenges encountered during SRv6 deployments.

**Scope:**
The SRv6OPS Working Group (WG) is dedicated to creating informational documents that provide deployment guidance, address operational issues, identify gaps, and explore potential operational experiments.

The development of protocols and protocol extensions is beyond the scope of the SRv6OPS WG. Additionally, the chairs of the SRv6OPS WG will consult with the Area Director (AD) before adopting documents that discuss operational considerations and guidance for SRv6-related technologies under development in other WGs (such as SPRING and 6MAN). Discussions and presentations aimed at raising awareness of operational artifacts and gathering feedback from the operator community deploying SRv6 are encouraged.

The SRv6OPS WG scope includes:

*Operational Issues and Requirements: Addressing IPv6 address planning for SRv6 Segment Identifiers (SIDs), protection, inter-domain, and interworking with other technologies.

*Deployment Scenarios: Considering operational considerations for various network environments and use cases.

*SRv6 Network Management Guidance: Providing insights on configuration, observability, assurance, and performance optimization.

**Key Deliverables:**
The SRv6OPS WG will focus on the following items:

*Documenting SRv6 deployment experiences and best practices, including different deployment scenarios (metro, core, and enterprise networks), scalability, and inter-domain implementations.

*Providing recommendations and guidance for various aspects such as IPv6 address planning, block size allocation, and the division of global/local identifiers (gib/lib) for SRv6 SIDs, both with and without SRv6 compression techniques essential for effective network management.

*Providing SRv6 network management guidance for configuration, automation, and performance optimization.

*Developing SRv6 network observability guidance for assurance and troubleshooting.

**Relationships with Other WGs:**
The SRv6OPS WG will collaborate with other WGs as necessary. Key interactions include (but are not limited to):

*SPRING WG: Close cooperation on SRv6 protocol extensions, new requirements, and operational considerations.

*v6ops WG: Sharing best practices and addressing deployment challenges.

*6man WG: Collaboration on core IPv6 functionalities, requirements, and operational considerations.

*BESS WG: Close cooperation on SRv6 based BESS WG protocol extensions, new service transport requirements, and operational considerations.

*IDR WG: Close cooperation on SRv6 based BGP protocol extensions, new SRv6 based attributes and encodings, and operational considerations.

The chairs will ensure that Working Group Last Call (WGLC) notices are cross-posted to the relevant WGs.

##########################
###end rewrite proposal###
##########################

[Ballot block]
About the charter I identified five issues. In context of these observations i added a slightly re-edited charter text blob for your convenience (see below). :

ISSUE#1:
WAS: "* Recommendations and guidance for IPv6 address planning for SRv6 SID, including SRv6 compression.:
PROBLEM: I am not sure i understand this assertion. May I assume that the text is intending to suggest about recommendations about block size, gib/lib split, etc... This may be more explicit in the charter.
REWRITE: "*Providing recommendations and guidance for various aspects such as IPv6 address planning, block size allocation, and the division of global/local identifiers (gib/lib) for SRv6 SIDs, both with and without SRv6 compression techniques essential for effective network management."

ISSUE#2:
WAS: " Discussions and presentations to increase awareness about potential operational issues for feedback from the operator's community are welcome."
PROBLEM: This is very open ended. This may end up as a rathole opportunity for people that do not want to implement SRv6 due to perceived security issues or other perceived operational disasters.
REWRITE: "Discussions and presentations aimed at raising awareness of operational artifacts and gathering feedback from the operator community deploying SRv6 are encouraged."

ISSUE#3:
PROBLEM: Network services are updated to operate with SRv6. Such work has been happening in IDR and BESS WG. It would be worthwhile to add these into the collaboration and awareness section.
ADD:
  *BESS WG: Close cooperation on SRv6 based BESS WG protocol extensions, new service transport requirements, and operational considerations.
  *IDR WG: Close cooperation on SRv6 based BGP protocol extensions, new SRv6 based attributes and encodings, and operational considerations.

ISSUE#4:
WAS: "* SRv6 deployment experience and best practices, including deployment scenarios (metro, core and enterprise networks), scale-up capability, and inter-domain implementations."
PROBLEM: I believe that the terminology “best practices” is misleading from an SRv6 deployment perspective at this point in time. I suppose, and in fact expect, this WG *not* to produce any BCP. From that perspective the use of “best practices” is misleading. I feel ok with producing informational documents
REWRITE: "The SRv6OPS Working Group (WG) is dedicated to creating informational documents that provide deployment guidance, address operational issues, identify gaps, and explore potential operational experiments."

ISSUE#5:
PROBLEM: It can be observed that the second sentence of SPRING's charter says:
  "...SPRING WG serves as a forum to discuss SPRING networks operations..."
FIX: Update SPRING charter to exclude SRv6 operations from the charter and de-conflict ownership.

Proposed Re-edit charter text blob :

[Ballot block]
About the charter I identified five issues. In context of these observations i added a slightly re-edited charter text blob for your convenience (see below). :

ISSUE#1:
WAS: "* Recommendations and guidance for IPv6 address planning for SRv6 SID, including SRv6 compression.:
PROBLEM: I am not sure i understand this assertion. May I assume that the text is intending to suggest about recommendations about block size, gib/lib split, etc... This may be more explicit in the charter.
REWRITE: "*Providing recommendations and guidance for various aspects such as IPv6 address planning, block size allocation, and the division of global/local identifiers (gib/lib) for SRv6 SIDs, both with and without SRv6 compression techniques essential for effective network management."

ISSUE#2:
WAS: " Discussions and presentations to increase awareness about potential operational issues for feedback from the operator's community are welcome."
PROBLEM: This is very open ended. This may end up as a rathole opportunity for people that do not want to implement SRv6 due to perceived security issues or other perceived operational disasters.
REWRITE: "Discussions and presentations aimed at raising awareness of operational artifacts and gathering feedback from the operator community deploying SRv6 are encouraged."

ISSUE#3:
PROBLEM: Network services are updated to operate with SRv6. Such work has been happening in IDR and BESS WG. It would be worthwhile to add these into the collaboration and awareness section.
ADD:
  *BESS WG: Close cooperation on SRv6 based BESS WG protocol extensions, new service transport requirements, and operational considerations.
  *IDR WG: Close cooperation on SRv6 based BGP protocol extensions, new SRv6 based attributes and encodings, and operational considerations.

ISSUE#4:
WAS: "* SRv6 deployment experience and best practices, including deployment scenarios (metro, core and enterprise networks), scale-up capability, and inter-domain implementations."
PROBLEM: I believe that the terminology “best practices” is misleading from an SRv6 deployment perspective at this point in time. I suppose, and in fact expect, this WG *not* to produce any BCP. From that perspective the use of “best practices” is misleading. I feel ok with producing informational documents
REWRITE: "The SRv6OPS Working Group (WG) is dedicated to creating informational documents that provide deployment guidance, address operational issues, identify gaps, and explore potential operational experiments."

ISSUE#5:
PROBLEM: I observed that the second sentence of SPRING's charter says:
  "...SPRING WG serves as a forum to discuss SPRING networks operations..."
FIX: Update SPRING charter to exclude SRv6 operations from the charter and de-conflict ownership.

Proposed Re-edit charter text blob :

[Ballot comment]
############################
###start rewrite proposal###
############################

Proposed Charter for SRv6 Operations (SRv6OPS)

The Segment Routing (SR) implementation on the IPv6 data plane is known as SRv6.

**Mission:**
The SRv6OPS Working Group (WG) is dedicated to the operational aspects of deploying and managing Segment Routing over IPv6 (SRv6) networks. Our mission includes:

*Gathering input from network operators to identify operational issues in SRv6 networks.

*Developing best practices and operational guidelines to ensure secure, reliable, efficient, and scalable SRv6 network operations.

*Identifying and resolving operational challenges encountered during SRv6 deployments.

**Scope:**
The SRv6OPS Working Group (WG) is dedicated to creating informational documents that provide deployment guidance, address operational issues, identify gaps, and explore potential operational experiments.

The development of protocols and protocol extensions is beyond the scope of the SRv6OPS WG. Additionally, the chairs of the SRv6OPS WG will consult with the Area Director (AD) before adopting documents that discuss operational considerations and guidance for SRv6-related technologies under development in other WGs (such as SPRING and 6MAN). Discussions and presentations aimed at raising awareness of operational artifacts and gathering feedback from the operator community deploying SRv6 are encouraged.

The SRv6OPS WG scope includes:

*Operational Issues and Requirements: Addressing IPv6 address planning for SRv6 Segment Identifiers (SIDs), protection, inter-domain, and interworking with other technologies.

*Deployment Scenarios: Considering operational considerations for various network environments and use cases.

*SRv6 Network Management Guidance: Providing insights on configuration, observability, assurance, and performance optimization.

**Key Deliverables:**
The SRv6OPS WG will focus on the following items:

*Documenting SRv6 deployment experiences and best practices, including different deployment scenarios (metro, core, and enterprise networks), scalability, and inter-domain implementations.

*Providing recommendations and guidance for various aspects such as IPv6 address planning, block size allocation, and the division of global/local identifiers (gib/lib) for SRv6 SIDs, both with and without SRv6 compression techniques essential for effective network management.

*Providing SRv6 network management guidance for configuration, automation, and performance optimization.

*Developing SRv6 network observability guidance for assurance and troubleshooting.

**Relationships with Other WGs:**
The SRv6OPS WG will collaborate with other WGs as necessary. Key interactions include (but are not limited to):

*SPRING WG: Close cooperation on SRv6 protocol extensions, new requirements, and operational considerations.

*v6ops WG: Sharing best practices and addressing deployment challenges.

*6man WG: Collaboration on core IPv6 functionalities, requirements, and operational considerations.

*BESS WG: Close cooperation on SRv6 based BESS WG protocol extensions, new service transport requirements, and operational considerations.

*IDR WG: Close cooperation on SRv6 based BGP protocol extensions, new SRv6 based attributes and encodings, and operational considerations.

The chairs will ensure that Working Group Last Call (WGLC) notices are cross-posted to the relevant WGs.

##########################
###end rewrite proposal###
##########################

[Ballot block]
About the charter I identified five issues. In context of these observations i added a slightly re-edited charter text blob for your convenience (see below). :

ISSUE#1:
WAS: "* Recommendations and guidance for IPv6 address planning for SRv6 SID, including SRv6 compression.:
PROBLEM: I am not sure i understand this assertion. May I assume that the text is intending to suggest about recommendations about block size, gib/lib split, etc... This may be more explicit in the charter.
REWRITE: "*Providing recommendations and guidance for various aspects such as IPv6 address planning, block size allocation, and the division of global/local identifiers (gib/lib) for SRv6 SIDs, both with and without SRv6 compression techniques essential for effective network management."

ISSUE#2:
WAS: " Discussions and presentations to increase awareness about potential operational issues for feedback from the operator's community are welcome."
PROBLEM: This is very open ended. This may end up as a rathole opportunity for people that do not want to implement SRv6 due to perceived security issues or other perceived operational disasters.
REWRITE: "Discussions and presentations aimed at raising awareness of operational artifacts and gathering feedback from the operator community deploying SRv6 are encouraged."

ISSUE#3:
PROBLEM: Network services are updated to operate with SRv6. Such work has been happening in IDR and BESS WG. It would be worthwhile to add these into the collaboration and awareness section.
ADD:
  *BESS WG: Close cooperation on SRv6 based BESS WG protocol extensions, new service transport requirements, and operational considerations.
  *IDR WG: Close cooperation on SRv6 based BGP protocol extensions, new SRv6 based attributes and encodings, and operational considerations.

ISSUE#4:
WAS: "* SRv6 deployment experience and best practices, including deployment scenarios (metro, core and enterprise networks), scale-up capability, and inter-domain implementations."
PROBLEM: I believe that the terminology “best practices” is misleading from an SRv6 deployment perspective at this point in time. I suppose, and in fact expect, this WG *not* to produce any BCP. From that perspective the use of “best practices” is misleading. I feel ok with producing informational documents
REWRITE: "The SRv6OPS Working Group (WG) is dedicated to creating informational documents that provide deployment guidance, address operational issues, identify gaps, and explore potential operational experiments."

ISSUE#5:
PROBLEM: I observed that the second sentence of SPRING's charter says:
  "...SPRING WG serves as a forum to discuss SPRING networks operations..."
FIX: Update SPRING charter to exclude SRv6 operations from the charter and de-conflict ownership.

Proposed Re-edit charter text blob :

############################
###start rewrite proposal###
############################

Proposed Charter for SRv6 Operations (SRv6OPS)

The Segment Routing (SR) implementation on the IPv6 data plane is known as SRv6.

**Mission:**
The SRv6OPS Working Group (WG) is dedicated to the operational aspects of deploying and managing Segment Routing over IPv6 (SRv6) networks. Our mission includes:

*Gathering input from network operators to identify operational issues in SRv6 networks.
*Developing best practices and operational guidelines to ensure secure, reliable, efficient, and scalable SRv6 network operations.
*Identifying and resolving operational challenges encountered during SRv6 deployments.

**Scope:**
The SRv6OPS Working Group (WG) is dedicated to creating informational documents that provide deployment guidance, address operational issues, identify gaps, and explore potential operational experiments.

The development of protocols and protocol extensions is beyond the scope of the SRv6OPS WG. Additionally, the chairs of the SRv6OPS WG will consult with the Area Director (AD) before adopting documents that discuss operational considerations and guidance for SRv6-related technologies under development in other WGs (such as SPRING and 6MAN). Discussions and presentations aimed at raising awareness of operational artifacts and gathering feedback from the operator community deploying SRv6 are encouraged.

The SRv6OPS WG scope includes:

*Operational Issues and Requirements: Addressing IPv6 address planning for SRv6 Segment Identifiers (SIDs), protection, inter-domain, and interworking with other technologies.
*Deployment Scenarios: Considering operational considerations for various network environments and use cases.
*SRv6 Network Management Guidance: Providing insights on configuration, observability, assurance, and performance optimization.

**Key Deliverables:**
The SRv6OPS WG will focus on the following items:

*Documenting SRv6 deployment experiences and best practices, including different deployment scenarios (metro, core, and enterprise networks), scalability, and inter-domain implementations.
*Providing recommendations and guidance for various aspects such as IPv6 address planning, block size allocation, and the division of global/local identifiers (gib/lib) for SRv6 SIDs, both with and without SRv6 compression techniques essential for effective network management.
*Providing SRv6 network management guidance for configuration, automation, and performance optimization.
*Developing SRv6 network observability guidance for assurance and troubleshooting.

**Relationships with Other WGs:**
The SRv6OPS WG will collaborate with other WGs as necessary. Key interactions include (but are not limited to):

*SPRING WG: Close cooperation on SRv6 protocol extensions, new requirements, and operational considerations.
*v6ops WG: Sharing best practices and addressing deployment challenges.
*6man WG: Collaboration on core IPv6 functionalities, requirements, and operational considerations.
*BESS WG: Close cooperation on SRv6 based BESS WG protocol extensions, new service transport requirements, and operational considerations.
*IDR WG: Close cooperation on SRv6 based BGP protocol extensions, new SRv6 based attributes and encodings, and operational considerations.

The chairs will ensure that Working Group Last Call (WGLC) notices are cross-posted to the relevant WGs.

##########################
###end rewrite proposal###
##########################

*Editor note: We are in the process of trying to convert the BoF group into a WG. This means that the list address is currently incorrect, there are no chairs listed, etc... Please be patient while we turn the administrative crank...*