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

[Alvaro Retana <[e-mail]>]

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

===== ===== ===== ===== =====