Hi Alvaro,

On Wed, Sep 4, 2024 at 5:31 AM Alvaro Retana <aretana.i...@gmail.com> wrote:

> Dear WG:
>
> As mentioned in July [1] and discussed in Vancouver [2], we have
> started the process to recharter the WG.  This email starts a two-week
> call for comments on the updated charter until EOD on September 18,
> 2024.
>
> Once this call for comments is over, we will let our AD handle the process.
>
>
The charter looks good.



> I have pasted the proposed charter below.  I am also attaching a set
> of diffs with respect to the current charter.
>
> 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
> include specific milestones reflecting the current/adopted work.
>
>
Thanks for doing that. It would be good to make that update before we send
out the charter to the IESG.

Thanks!
Dhruv



>
> Please take a look (below) and reply with comments or proposed text.
>
> Thanks!
>
> Alvaro (for spring-chairs)
>
>
> [1]
> https://mailarchive.ietf.org/arch/msg/spring/xebGJFcbxpv44q06y81gEpHXH-w/
>
> [2]
> https://datatracker.ietf.org/doc/minutes-120-spring-202407262000/#1300-spring-status---chairs-15-mins
>
>
> ===== 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 an SR 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 SR nodes can achieve full path
> control (through loose or strict path specification). However, SR
> 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 and milestones
> based on WG engagement and successful adoption.
>
> 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 -- spring@ietf.org
> To unsubscribe send an email to spring-le...@ietf.org
>
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org

Reply via email to