It looks good to me, the revision makes the logic more clear. BR, Cheng
-----Original Message----- From: Alvaro Retana <aretana.i...@gmail.com> Sent: Wednesday, September 4, 2024 2:00 AM To: SPRING WG <spring@ietf.org> Cc: spring-cha...@ietf.org Subject: [spring] Call for Comments: spring charter Update (Ends Sep/18.2024 / charter-ietf-spring) 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. 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. 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
