Re: [spring] Updating the SPRING WG Charter

[Rob Shakir <[e-mail]>]

Hi Linda,

On Fri, Jun 1, 2018 at 12:35 PM Linda Dunbar <[e-mail]>
wrote:

>
>
> The Source Packet Routing in NetworkinG (SPRING) Working Group is the home
> of
>
> Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6).
>
> [jeff] I’d add “dataplanes”
>
> SPRING WG serves as
>
> a forum to discuss SPRING networks operations, define new applications, and
>
> specify extensions of Segment Routing technologies.
>
> [Linda] Does the “new applications” in the sentence above refer to the
> “Use cases” for SPRING?
>
> Is the “Extensions” being discussed in SPRING also include the
> “extensions” to other protocols?
>

robjs> The aim here is to define that SPRING is where we discuss new things
that are done with SR. I don't think we want to constrain things to say
that only use-case work is done in SPRING (actually, we've had little
success with a number of the use case documents). The extensions referred
to are extensions to SR technologies. Per the later wording in the charter,
the intention here is to clarify that functional specifications for those
extensions can be done in SPRING, but the actual extension work is owned by
the WG that owns that technology.

robjs> You can imagine the SR-TE policy work breaks down this way: we
discuss the "application" which is steering traffic onto sets of SR paths,
and define a functional specification document for how that works. If that
is realised in BGP (as it is being today), IDR owns the protocol
specification, if it's in PCEP, then it's done in that WG.


>  *snip*
>
o Source-routed stateless service chaining using SR-MPLS and SRv6
> dataplanes.
>
>
>
> [Linda] o Source-routed stateless SD-WAN paths traversing through SR
> domain (i.e. SR as part of SD-WAN’s underlay network)
>

robjs> Our focus here is to provide a constrained set of areas where there
is a need for work within SPRING. The discussions that we had in the
working group in London were focused around capturing the set of
technologies that have strong support and folks to work on. If we have new
proposals around this work, then we can always consider working on them if
they need extensions to the SR architecture. At the moment, the preference
is to keep this list constrained such that we can focus the working group.


>  *snip*
>
>
>
> o The inter-working between SRv6 and SR-MPLS.
>
>
>
> [Linda] o The inter-working between SR and legacy networks (which is far
> more likely than SRv6 & SR-MPLS interworking)
>

robjs> The LDP interop draft is something that is going to the IESG at the
moment. There is existing work in TEAS (in WGLC) that covers co-existence
of RSVP-TE and SR. Are there specific areas that we have gaps? The reason
that we call out SRv6/SR-MPLS interop is that there has been some
discussion of this, and we have not got an answer for this yet.

Thanks for the comments.

Kind regards,
r.

>