[spring] Re: spring Charter Update (charter-ietf-spring)

[Greg Mirsky <[e-mail]>]

Hi Alvaro,
thank you for sharing the proposed updates to the SPRING charter. It all
looks good to me. I have a minor proposal to the extend the list of the
topics on which SPRING collaborates and coordinates adding the following:
IPPM on performance measurement methods and metrics

Regards,
Greg



On Fri, Jul 12, 2024 at 6:17 AM Alvaro Retana <[e-mail]>
wrote:

> Dear WG:
>
> We last updated the WG's charter almost 6 years ago. Given the time
> and the recent chartering of the srv6ops WG, it is time to look at it
> again. :-)
>
> Besides any changes to consider srv6ops (minimum), the proposed
> charter focuses on describing the scope of the expected work. As it is
> today, any extension work will be done in other WGs.
>
> We intend to manage the WG based on milestones. IOW, the plan is not
> to list specific work items in the charter text. Nonetheless, we will
> need to include specific milestones, which I would initially expect to
> reflect the current/adopted work.
>
>
> Please take a look (below) and send any comments. We will also
> dedicate a few minutes at the Vancouver meeting to discuss the text.
>
> Thanks!
>
> Alvaro, for the spring-chairs.
>
>
> ===== Proposed Charter =====
>
> The Source Packet Routing in NetworkinG (SPRING) Working Group is the
> home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6).
> The SPRING WG is responsible for defining new applications and
> specifying extensions of Segment Routing technologies. It also serves
> as a forum to discuss SR-MPLS network operations.
>
> The work in the SPRING WG should avoid modification to existing data
> planes that would make them incompatible with existing deployments.
> Where possible, existing control and management plane protocols must
> be used within existing architectures to implement the SPRING
> function. Any modification of -or extension to- existing
> architectures, data planes, or control or management plane protocols
> should be carried out in the WGs responsible for the architecture,
> data plane, or control or management plane protocol being modified
> and in coordination with the SPRING WG, but may be done in SPRING WG
> after agreement with all the relevant WG chairs and responsible Area
> Directors.
>
> The SPRING WG defines procedures that allow a node to steer a packet
> through an SR Policy instantiated as an ordered list of instructions
> called segments without needing per-path state information at transit
> nodes. A network comprising only SPRING nodes can achieve full path
> control (through loose or strict path specification). However, SPRING
> nodes must interoperate through loose routing in existing networks.
>
> By default, Segment Routing operates within a trusted domain and
> requires the enforcement of a strict boundary to prevent Segment
> Routing packets from entering the trusted domain [rfc8402]. Some
> deployments may involve multiple trusted domains and the use of
> cross/inter-domain segments. Documents which deal with such
> situations need to include a risk analysis and use mechanisms to
> validate that the segment list is provided by an authorized entity
> and has not been modified in transit.
>
> The SPRING WG will manage its specific work items based on WG input
> and according to milestones agreed upon with the responsible Area
> Director.
>
> The SPRING WG will coordinate and collaborate with other WGs as
> needed. Specific expected interactions include (but may not be
> limited to):
>
> mpls on the MPLS data plane and associated extensions
> 6man on the IPv6 data plane and associated extensions
> lsr on OSPF and IS-IS extensions
> idr on BGP extensions
> bess on VPN control plane
> pce on extensions for centralized solutions
> teas on traffic engineering architecture
> rtgwg on fast-reroute technologies
> srv6ops on SRv6 operations
>
> ===== ===== ===== ===== =====
> _______________________________________________
> spring mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>