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 ===== ===== ===== ===== =====
<<< text/html; charset="US-ASCII"; name="charter-ietf-spring-02.diff.html": Unrecognized >>>
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
