Subject: [spring] Updating the SPRING WG Charter

From: Rob Shakir <[email-masked]>
Date: Fri, 1 Jun 2018 09:05:53 -0700

Hi SPRING,

After the discussions on the list and in London relating to the charter,
Bruno and I have been working to propose a new charter for the WG with
Martin, and the other routing ADs. The text for this suggested charter is
below. We would like to solicit WG feedback on the charter text prior to
Martin taking to the IESG. We'd like to try and get the charter agreed
prior to IETF 102 in Montréal.

The Source Packet Routing in NetworkinG (SPRING) Working Group is the home
of
Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6). SPRING WG serves
as
a forum to discuss SPRING networks operations, define new applications, and
specify extensions of Segment Routing technologies.

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
and
without the need for per-path state information to be held at transit nodes.
Full explicit control (through loose or strict path specification) can be
achieved in a network comprising only SPRING nodes, however SPRING nodes
must
inter-operate through loose routing in existing networks and may find it
advantageous to use loose routing for other network applications.

The scope of the SPRING WG work includes both single Autonomous System (AS)
and
multi-AS environments. Segment Routing operates within a trusted domain; as
described in the architecture, a node imposing a segment list is assumed to
be
allowed to do so. Nonetheless, the SPRING WG must strive to identify and
address security considerations brought up by the technologies it defines.
The
technologies SPRING WG defines may be applicable to both centralised and
distributed path computation.

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 will manage its specific work items by milestones agreed with
the
responsible Area Director.

The work-items of the SPRING WG include functional specifications for:

o Segment Routing policies and the associated steering and traffic
engineering
  mechanisms.

o Source-routed stateless service chaining using SR-MPLS and SRv6
dataplanes.

o SRv6 network programming for the underlay networks and overlay services,
and
  including data plane behavior and functions associated with SIDs

o Operation, Administration and Management (OAM), and traffic accounting in
  networks with SR-MPLS and SRv6 data planes in the case where SR introduces
  specificities compared to MPLS or IPv6 technologies.

o Performance Management (PM) and monitoring in networks with SR-MPLS and
SRv6
  data planes in the case where SR introduces specificities compared to
MPLS or
  IPv6 technologies.

o The inter-working between SRv6 and SR-MPLS.

o Using SR as the mechanism to identify sets of resources in networks with
  SR-MPLS and SRv6 dataplanes.

Any of the above may require architectural extensions.

The work-items of SPRING WG also include:

o Specification of management models (YANG) for Segment Routing
applications,
  services and networks with SR-MPLS and SRv6 dataplanes.

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 dataplane and OAM extensions,
* 6man on the IPv6 dataplane for SR and associated OAM extensions
* lsr on OSPF and IS-IS extensions to flood SPRING-related information
        * idr for BGP extensions
* bess for VPN control plane
* pce on extensions to communicate with an external entity to compute and
program SPRING paths
* teas on generic traffic engineering architecture

Please comment on the contents of the charter text on the list.

Thanks,
Bruno & Rob

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 01 Jun 2018 09:43:52 -0700

Hi Rob,

Looks good, few additions, please see inline 

Cheers,

Jeff

From: spring <[email-masked]> on behalf of Rob Shakir <robjs=[email-masked]>
Date: Friday, June 1, 2018 at 09:05
To: SPRING WG List <[email-masked]>
Subject: [spring] Updating the SPRING WG Charter

Hi SPRING,

After the discussions on the list and in London relating to the charter, Bruno and I have been working to propose a new charter for the WG with Martin, and the other routing ADs. The text for this suggested charter is below. We would like to solicit WG feedback on the charter text prior to Martin taking to the IESG. We'd like to try and get the charter agreed prior to IETF 102 in Montréal.

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

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 and

achieved in a network comprising only SPRING nodes, however SPRING nodes must

The scope of the SPRING WG work includes both single Autonomous System (AS) and

described in the architecture, a node imposing a segment list is assumed to be

address security considerations brought up by the technologies it defines.  The

them incompatible with existing deployments. Where possible, existing control

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

 

The SPRING WG will manage its specific work items by milestones agreed with the

o Segment Routing policies and the associated steering and traffic engineering

  mechanisms.

o Source-routed stateless service chaining using SR-MPLS and SRv6 dataplanes.

o SRv6 network programming for the underlay networks and overlay services, and

o Performance Management (PM) and monitoring in networks with SR-MPLS and SRv6

  data planes in the case where SR introduces specificities compared to MPLS or

  IPv6 technologies.

o Using SR

[jeff] SR conveyed metadata perhaps? Think of BSID x-connect into another layer

 as the mechanism to identify sets of resources in networks with

o Specification of management models (YANG) for Segment Routing applications,

The SPRING WG will coordinate and collaborate with other WGs as needed. Specific

[jeff] in RIFT we plan to support SR as well

        * idr for BGP extensions

     * pce on extensions to communicate with an external entity to compute and program SPRING paths

[jeff] rtgwg for fast convergence related topics

Thanks,

Bruno & Rob

_______________________________________________ spring mailing list [email-masked] https://www.ietf.org/mailman/listinfo/spring

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 1 Jun 2018 19:35:36 +0000

Hi Rob,

My suggestions (& comments) are inserted below.

Linda

From: spring [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Friday, June 01, 2018 11:44 AM
To: Rob Shakir <robjs=[email-masked]>; SPRING WG List <[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Rob,

Cheers,
Jeff
From: spring <spring-bounces@ietf..org<mailto:spring-bounces@ietf..org>> on behalf of Rob Shakir <robjs=[email-masked]<mailto:robjs=[email-masked]>>
Date: Friday, June 1, 2018 at 09:05
To: SPRING WG List <[email-masked]<mailto:[email-masked]>>
Subject: [spring] Updating the SPRING WG Charter

Hi SPRING,

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?

address security considerations brought up by the technologies it defines..  The

[Linda] o Source-routed stateless SD-WAN paths traversing through SR domain (i.e. SR as part of SD-WAN’s underlay network)

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

o Using SR

Thanks,
Bruno & Rob
_______________________________________________ spring mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/spring

---

From: James N Guichard <[email-masked]>
Date: Sat, 2 Jun 2018 00:41:41 +0000

Hi Rob,

Please can you add that the SPRING WG will cooperate and collaborate with the SFC WG for service function chaining.

Thanks!

Jim

From: spring [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Friday, June 01, 2018 12:44 PM
To: Rob Shakir <robjs=[email-masked]>; SPRING WG List <[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Rob,

Cheers,
Jeff

Hi SPRING,

o Using SR

Thanks,
Bruno & Rob

---

From: Rob Shakir <[email-masked]>
Date: Sun, 3 Jun 2018 14:32:13 -0700

Hi Linda,

> “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*
> 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*
> [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.

---

From: Rob Shakir <[email-masked]>
Date: Sun, 3 Jun 2018 14:36:24 -0700

Hi Jeff,

Thanks for the comments.

> [jeff] I’d add “dataplanes”

robjs> I don't think that SPRING should limit itself to having to just work
on dataplane technologies. The functional specifications or architectures
that are proposed are likely to span both data, control, and management
planes (e.g., YANG models, counter specifications). I'd be interested if
you disagree?

*snip*
> [jeff] SR conveyed metadata perhaps? Think of BSID x-connect into another

robjs> I'd argue that this is more than metadata, it's really a forwarding
instruction that says to send to some other layer, or that is interpreted
in another domain. Metadata to me would mean information that we're
carrying on the packet that *isn't* used for forwarding.

> [jeff] in RIFT we plan to support SR as well

robjs> This is probably RIFT co-ordinating with SPRING. I'd rather avoid
listing another protocol here without there being SPRING work that affects
it. Of course, please do involve SPRING in discussions of SR support in
RIFT.

> [jeff] rtgwg for fast convergence related topics

robjs> Thanks -- yes, given all the work in rtgwg on this topic, this
should definitely be added.

Thanks,
r.

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 6 Jun 2018 18:41:13 +0000

Hi Rob,

Re: Linda comment on SR assisted SD-WAN.

At IETF101, Bruno and you presented a slide based on the WG feedback on the mailing list (https://datatracker.ietf.org/meeting/101/materials/slides-101-spring-00-chairs-slides-01). During the Spring meeting, the WG agreed to add milestones against those items. In general, I see some milestones are not included in the proposed chartered text.

In the context of Linda’s feedback, the slide has the following text (with support during the WG meeting):

  *   Interactions between overlay/applications and optimized underlay
     *   E.g. SR-assisted SD-WAN, path awareness

We should add a milestone for specification of architecture, and the required protocol extensions for Segment Routing for interactions between overlay/ applications and optimized SR underlay MPLS and IPv6 data planes. I fully agree with you that the actual protocol extension work will be done at the WG that owns the protocol.

Thanks

Regards … Zafar

From: spring <[email-masked]> on behalf of Rob Shakir <robjs=[email-masked]>
Date: Sunday, June 3, 2018 at 5:32 PM
To: Linda Dunbar <[email-masked]>
Cc: Jeff Tantsura <[email-masked]>, SPRING WG List <[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Linda,

On Fri, Jun 1, 2018 at 12:35 PM Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

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*

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*

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.

---

From: "Bernier, Daniel" <[email-masked]>
Date: Mon, 11 Jun 2018 13:30:12 +0000

Hi Rob,

A bit late but +1 to Zafar's and Linda's comments on adding overlay/app interaction with underlay in the WG charter.

I presented at last IETF in PANRG (ref: https://datatracker.ietf.org/meeting/101/materials/slides-101-panrg-service-aware-networking-using-segment-routing-00) on this topic and I do think there is potential for a lot of extensions with regards to inter-carrier SR policy awareness and how it interacts at the host/app level as well.

Cheers,

Daniel Bernier

________________________________
From: spring <[email-masked]> on behalf of Zafar Ali (zali) <zali=[email-masked]>
Sent: Wednesday, June 6, 2018 2:41 PM
To: Rob Shakir; Linda Dunbar
Cc: Jeff Tantsura; Zafar Ali (zali); SPRING WG List
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Rob,

Thanks

Regards … Zafar

Hi Linda,

 *snip*

 *snip*

Thanks for the comments.

Kind regards,
r.

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Tue, 12 Jun 2018 13:45:17 +0000

Dear Rob, Bruno,

I have a question on the specifics of the following milestone:

  *   Using SR as the mechanism to identify sets of resources in networks with SR-MPLS and SRv6 dataplanes.

I do not know of any specific use-case, requirement or an individual draft associated with this milestone beyond what is already covered by other milestones (e.g., by “Segment Routing policies and the associated steering and traffic engineering mechanisms”). What specific deliverable you have in mind? Is there an individual(s) draft against this milestone? Please advise.

Thanks

Regards … Zafar

From: spring <[email-masked]> on behalf of Rob Shakir <robjs=[email-masked]>
Date: Friday, June 1, 2018 at 12:07 PM
To: SPRING WG List <[email-masked]>
Subject: [spring] Updating the SPRING WG Charter

Hi SPRING,

The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of
Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6). SPRING WG serves as
a forum to discuss SPRING networks operations, define new applications, and
specify extensions of Segment Routing technologies.

Thanks,
Bruno & Rob

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 12 Jun 2018 14:27:53 +0000

Zafar,
From my POV one possible answer to your question could be found in Section 4.3.6 and 4.4 of the Enhanced VPN<https://tools.ietf.org/html/draft-bryant-rtgwg-enhanced-vpn-02> draft.
This draft mentions new SR instructions that could, say, define not just forwarding behavior of packets but also their QoS treatment.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: spring [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Tuesday, June 12, 2018 4:45 PM
To: Rob Shakir <robjs=[email-masked]>; SPRING WG List <[email-masked]>
Cc: Zafar Ali (zali) <[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Dear Rob, Bruno,

&#0;.      Using SR as the mechanism to identify sets of resources in networks with SR-MPLS and SRv6 dataplanes.

Thanks

Regards … Zafar

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Rob Shakir <robjs=[email-masked]<mailto:robjs=[email-masked]>>
Date: Friday, June 1, 2018 at 12:07 PM
To: SPRING WG List <[email-masked]<mailto:[email-masked]>>
Subject: [spring] Updating the SPRING WG Charter

Hi SPRING,

Thanks,
Bruno & Rob

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________

---

From: <[email-masked]>
Date: Tue, 12 Jun 2018 16:13:19 +0000

Dear Zafar,

Please see inline [Bruno]

From: spring [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Tuesday, June 12, 2018 3:45 PM
To: Rob Shakir; SPRING WG List
Cc: Zafar Ali (zali)
Subject: Re: [spring] Updating the SPRING WG Charter

Dear Rob, Bruno,

[Bruno] Would the following pointers provide enough context?
https://mailarchive.ietf.org/arch/msg/spring/canXoxLZCwRZ_yFcV3U7RXRwfpM
https://tools.ietf.org/html/draft-bryant-rtgwg-enhanced-vpn-02#section-4.3.6
https://tools.ietf.org/html/draft-dong-spring-sr-for-enhanced-vpn-00#section-2

Regards,
--Bruno

Thanks

Regards … Zafar

Hi SPRING,

Thanks,
Bruno & Rob

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 12 Jun 2018 11:16:13 -0700

Rob,

Sorry for the delay, please see inline.

Thanks!

Cheers,

Jeff

From: Rob Shakir <[email-masked]>
Date: Sunday, June 3, 2018 at 14:36
To: Jeff Tantsura <[email-masked]>
Cc: SPRING WG List <[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Jeff,

Thanks for the comments.

On Fri, Jun 1, 2018 at 9:44 AM Jeff Tantsura <[email-masked]> wrote:

robjs> I don't think that SPRING should limit itself to having to just work on dataplane technologies. The functional specifications or architectures that are proposed are likely to span both data, control, and management planes (e.g., YANG models, counter specifications). I'd be interested if you disagree?

[jeff] I absolutely agree with you that the work should have all abovementioned planes, it is more to how the sentence reads, I meant not to limit the works to dataplane only but a common convention, when we say SR-MPLS we really mean SR with MPLS data plane, same for SRv6

*snip*

o Using SR

robjs> I'd argue that this is more than metadata, it's really a forwarding instruction that says to send to some other layer, or that is interpreted in another domain. Metadata to me would mean information that we're carrying on the packet that *isn't* used for forwarding.

[jeff] we’d disagree on this one, I would not consider setting the context (ie where to lookup) as a forwarding instruction  

*snip*

robjs> This is probably RIFT co-ordinating with SPRING. I'd rather avoid listing another protocol here without there being SPRING work that affects it. Of course, please do involve SPRING in discussions of SR support in RIFT.

[jeff] Ack

*snip*

robjs> Thanks -- yes, given all the work in rtgwg on this topic, this should definitely be added.

[jeff] thanks!

Thanks,

r.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 13 Jun 2018 12:18:43 +0000

Dear Zafar,

As Bruno and Sasha have pointed out, the enhanced VPN drafts are relevant to this work item.

As mentioned in one of my previous email (the pointer is also provided in Bruno’s mail), currently SR is mainly designed for source routing based path steering, comparing to RSVP-TE, it does not provide the functionality of allocating and identifying different set of resources on particular network segments. Although SR can rely on the network controller for global traffic optimization and placement, there is no mechanism to provide resource guarantee and service separation in the data plane. Some customers have expressed their concerns about SR’s lack of this kind of capability, thus we believe this work item should be included in the updated charter.

Best regards,
Jie

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, June 13, 2018 12:13 AM
To: Zafar Ali (zali) <zali=[email-masked]>
Cc: SPRING WG List <[email-masked]>; Zafar Ali (zali) <[email-masked]>; Rob Shakir <robjs=[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Dear Zafar,

Dear Rob, Bruno,

Regards,
--Bruno

Thanks

Regards … Zafar

Hi SPRING,

Thanks,
Bruno & Rob

Thank you.

---

From: <[email-masked]>
Date: Wed, 13 Jun 2018 13:16:59 +0000

Dear Ji,

you’ve written „Although SR can rely on the network controller for global traffic optimization and placement, there is no mechanism to provide resource guarantee and service separation in the data plane.”

If this is linked to maintenance of per segment (or per segment range) state on other parts of the SR domain than the SR edge router, it is not within charter of the SR WG, I think.

Regards,

Ruediger

Von: spring [mailto:[email-masked]] Im Auftrag von Dongjie (Jimmy)
Gesendet: Mittwoch, 13. Juni 2018 14:19
An: [email-masked]; Zafar Ali (zali) <zali=[email-masked]>
Cc: SPRING WG List <[email-masked]>; Zafar Ali (zali) <[email-masked]>; Rob Shakir <robjs=[email-masked]>
Betreff: Re: [spring] Updating the SPRING WG Charter

Dear Zafar,

Best regards,
Jie

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, June 13, 2018 12:13 AM
To: Zafar Ali (zali) <zali=[email-masked]<mailto:zali=[email-masked]>>
Cc: SPRING WG List <[email-masked]<mailto:[email-masked]>>; Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>; Rob Shakir <robjs=[email-masked]<mailto:robjs=[email-masked]>>
Subject: Re: [spring] Updating the SPRING WG Charter

Dear Zafar,

Dear Rob, Bruno,

Regards,
--Bruno

Thanks

Regards … Zafar

Hi SPRING,

Thanks,
Bruno & Rob

Thank you.

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 13 Jun 2018 15:29:49 +0000

Hi Bruno,

I am aware of the VPN+ draft but IMO this document or Slicing, in general, is an informational use-case document (E.g., similarly SD-WAN does not have a milestone in the Charter). I do not think that there is any new behavior needed beyond SRTE, SRVPN, Flex-Algo, Diffserv QoS and SR SFC, etc. What is missing is the controller doing the bandwidth (resource) accounting but this outside the scope of IETF. Furthermore, the specifics in the VPN+ specifics draft against this milestone are missing. The same comments were also raised when draft-dong-spring-sr-for-enhanced-vpn was presented to the Spring WG in London.

Thanks

Regards … Zafar

From: "[email-masked]" <[email-masked]>
Date: Tuesday, June 12, 2018 at 12:13 PM
To: "Zafar Ali (zali)" <zali=[email-masked]>
Cc: "Zafar Ali (zali)" <[email-masked]>, Rob Shakir <robjs=[email-masked]>, SPRING WG List <[email-masked]>
Subject: RE: [spring] Updating the SPRING WG Charter

Dear Zafar,

Dear Rob, Bruno,

Regards,
--Bruno

Thanks

Regards … Zafar

Hi SPRING,

Thanks,
Bruno & Rob

Thank you.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 14 Jun 2018 03:26:18 +0000

Hi Zafar,

As mentioned in my previous mail, the VPN+ drafts and this work item require new functionality to be added to SR, which is to associate SR with particular allocated resources and treatment. IMO this is not covered by existing SR mechanisms. It is different from Diffserv QoS, and it is not pure controller-based accounting, because in the data plane some mechanism is needed to make sure different services will be treated accordingly and not impact each other.

Thanks for the comments in London, we are working on the updates of the VPN+ drafts, hopefully they will be published for open review soon.

Best regards,
Jie

From: spring [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Wednesday, June 13, 2018 11:30 PM
To: [email-masked]; Zafar Ali (zali) <zali=[email-masked]>
Cc: SPRING WG List <[email-masked]>; Zafar Ali (zali) <[email-masked]>; Rob Shakir <robjs=[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Bruno,

Thanks

Regards … Zafar

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, June 12, 2018 at 12:13 PM
To: "Zafar Ali (zali)" <zali=[email-masked]<mailto:zali=[email-masked]>>
Cc: "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>, Rob Shakir <robjs=[email-masked]<mailto:robjs=[email-masked]>>, SPRING WG List <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] Updating the SPRING WG Charter

Dear Zafar,

Dear Rob, Bruno,

Regards,
--Bruno

Thanks

Regards … Zafar

Hi SPRING,

Thanks,
Bruno & Rob

Thank you.

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 14 Jun 2018 11:43:49 +0000

Hi Jie,

While I look forward to reviewing the draft, at the moment of writing the charter no such details were available. At the moment we do not know if this would be an architecturally correct option to adopt in segment routing; what type of complexity, statefulness and scalability concerns it brings to the table. We also don't know if this is a matter of local implementation or are we better off if it is entirely done at the controller, etc.

The work you are doing is already in the charter by the virtue of "SPRING WG serves as a forum to discuss SPRING networks operations, define new applications, and specify extensions of Segment Routing technologies."

What puzzles me is the logic of adding this task to the "work items" list. And if we go with the same logic, why did we drop a few items raised by many (before/ during IETF in London and as part of the review of the charter draft) on the list for inclusion in the "work items" list. I am hoping for consistency in making such determination in the final version of the charter.

Thanks

Regards … Zafar

From: spring <[email-masked]> on behalf of "Dongjie (Jimmy)" <[email-masked]>
Date: Wednesday, June 13, 2018 at 11:26 PM
To: "Zafar Ali (zali)" <zali=[email-masked]>, "[email-masked]" <[email-masked]>
Cc: SPRING WG List <[email-masked]>, "Zafar Ali (zali)" <[email-masked]>, Rob Shakir <robjs=[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Zafar,

Best regards,
Jie

Hi Bruno,

Thanks

Regards … Zafar

Dear Zafar,

Dear Rob, Bruno,

Regards,
--Bruno

Thanks

Regards … Zafar

Hi SPRING,

Thanks,
Bruno & Rob

Thank you.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 15 Jun 2018 15:13:04 +0000

Hi Zafar,

I’d like to remind you that in the current SPRING charter there is already one work item as below:

 o    Some types of network virtualization, including multi-
       topology networks and the partitioning of network
       resources for VPNs

IMO the work item you are referring to is not a new one, actually it is an update or rephrasing of the previous one. Thus it is not relevant to the logic of adding new work items. The VPN+ drafts are just piece of work matching with this existing work item.

I believe there is consistent rules of adding new work items to the charter, and it would be very helpful to concentrate on constructive discussion of those topics.

Best regards,
Jie

发件人: Zafar Ali (zali) [mailto:[email-masked]]
发送时间: 2018年6月14日 19:44
收件人: Dongjie (Jimmy) <[email-masked]>; Zafar Ali (zali) <zali=[email-masked]>; [email-masked]
抄送: SPRING WG List <[email-masked]>; Rob Shakir <robjs=[email-masked]>; Zafar Ali (zali) <[email-masked]>
主题: Re: [spring] Updating the SPRING WG Charter

Hi Jie,

Thanks

Regards … Zafar

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of "Dongjie (Jimmy)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 13, 2018 at 11:26 PM
To: "Zafar Ali (zali)" <zali=[email-masked]<mailto:zali=[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG List <[email-masked]<mailto:[email-masked]>>, "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>, Rob Shakir <robjs=[email-masked]<mailto:robjs=[email-masked]>>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Zafar,

Best regards,
Jie

To: [email-masked]<mailto:[email-masked]>; Zafar Ali (zali) <zali=[email-masked]<mailto:zali=[email-masked]>>

Hi Bruno,

Thanks

Regards … Zafar

Dear Zafar,

Dear Rob, Bruno,

Regards,
--Bruno

Thanks

Regards … Zafar

Hi SPRING,

Thanks,
Bruno & Rob

Thank you.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 19 Jun 2018 12:18:57 +0100

> without the need for per-path state information to be held at transit 

I am not sure where the line gets drawn with the per-path state 
statement. If I introduce a
binding-SID to allow the creation of a path, have I introduced per-path 
state or not? In practise
a management entity will choose between the infinity of possible 
binding-SIDs by considering
the need to create specific paths and I would imagine that many will be 
instantiated just-in-time.

I think that the key point is that the ingress creates the path by using 
SIDs to create
a concatenation of paths, policies and resources. However it could be 
argued that
as soon as we introduced Binding SIDs we introduced per-path state. I 
think we might
be best served by deleting the text I have highlighted.

- Stewart

---

From: <[email-masked]>
Date: Tue, 19 Jun 2018 11:46:22 +0000

There’s no objection against policies installed at ingress interfaces to an SR domain. Rob correctly states, that the SR architecture does not require per path state at transit nodes. And that’s good and correct. I’d like to see the number of signaling protocols in the SR core network being reduced as compared with today’s MPLS network, not increased.

There’s RSVP-TE for MPLS, which can be deployed for services requiring per path state at transit nodes.

Regards,

Ruediger

Von: spring [mailto:[email-masked]] Im Auftrag von Stewart Bryant
Gesendet: Dienstag, 19. Juni 2018 13:19
An: Rob Shakir <robjs=[email-masked]>; SPRING WG List <[email-masked]>
Betreff: Re: [spring] Updating the SPRING WG Charter

I am not sure where the line gets drawn with the per-path state statement. If I introduce a
binding-SID to allow the creation of a path, have I introduced per-path state or not? In practise
a management entity will choose between the infinity of possible binding-SIDs by considering
the need to create specific paths and I would imagine that many will be instantiated just-in-time.

I think that the key point is that the ingress creates the path by using SIDs to create
a concatenation of paths, policies and resources. However it could be argued that
as soon as we introduced Binding SIDs we introduced per-path state. I think we might
be best served by deleting the text I have highlighted.

- Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 19 Jun 2018 12:08:43 +0000

Stewart,
Lots of thanks for presenting this issue up front.

I had similar concerns regarding Binding SIDs introducing per-path state in transit nodes.

One possible argument against such a conclusion is that a Binding SID (similar to Adj-SID) can be used by multiple end-to-end paths. So the state it adds is not necessarily a per-path state.

At the same time from my POV elimination of per-path state in transit routers is the main differentiator between the SR and other mechanisms for traffic steering. So I would not hurry to remove the text that you have highlighted.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: spring [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Tuesday, June 19, 2018 2:19 PM
To: Rob Shakir <robjs=[email-masked]>; SPRING WG List <[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

- Stewart

---

From: <[email-masked]>
Date: Tue, 19 Jun 2018 12:38:21 +0000

Hi Stewart,

Speaking as individual contributor, please see inline [Bruno]

From: spring [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Tuesday, June 19, 2018 1:19 PM

I think that the key point is that the ingress creates the path by using SIDs to create
a concatenation of paths, policies and resources.
[Bruno] Agreed. And it can be argued that this creates a state on the ingress. An “outgoing” state, very roughly comparable to Next Hop Label Forwarding Entry (NHLFE))
However it could be argued that
as soon as we introduced Binding SIDs we introduced per-path state.
[Bruno] Adding a Binding SID to this SR policy introduces an “incoming” state, very roughly comparable to Incoming Label Map (ILM). But this gets additional benefit as it allows others SR nodes to use this state/SR policy.
I’m not sure that in such high level text, we need to make such distinction.
I think we might
be best served by deleting the text I have highlighted.

[Bruno] This text is mostly a copy/past from existing charter so is not really new:

 “allow a node to steer a packet along an explicit
  route using information attached to the packet and
  without the need for per-path state information to be
  held at transit nodes. ”

At high level, I believe that this is a key distinction of spring/segment routing hence worth keeping in the high level introduction of the WG.
Now do we need to add text about more specific details, such as BSID? I’d rather not, as I don’t see what this would bring. I also don’t think that this sentence prohibits the creation of states when required/useful.
--Bruno

- Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 19 Jun 2018 13:37:41 +0000

Bruno, Stewart and all,
I have looked up Section 5 “Binding Segment” of the Segment Routing Architecture<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15> draft, and it says:

   In order to provide greater scalability, network opacity, and service
   independence, SR utilizes a Binding SID (BSID).  The BSID is bound to
   an SR policy, instantiation of which may involve a list of SIDs.  Any
   packets received with active segment = BSID are steered onto the
   bound SR Policy.

   A BSID may either be a local or a global SID.  If local, a BSID
   SHOULD be allocated from the SRLB.  If global, a BSID MUST be
   allocated from the SRGB.

   Use of a BSID allows the instantiation of the policy (the SID list)
   to be stored only on the node(s) which need to impose the policy.
   Direction of traffic to a node supporting the policy then only
   requires imposition of the BSID.  If the policy changes, this also
   means that only the nodes imposing the policy need to be updated.
   Users of the policy are not impacted.

From my POV this definition is fully aligned both with the Bruno’s last email and with my earlier argument why a BSID does not add a per-path state in the transit nodes.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, June 19, 2018 3:38 PM
To: Stewart Bryant <[email-masked]>
Cc: SPRING WG List <[email-masked]>; Rob Shakir <robjs=[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Stewart,

- Stewart

Thank you.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 19 Jun 2018 16:48:26 +0100

On 19/06/2018 13:38, [email-masked] wrote:
> *From:*spring [mailto:[email-masked]] *On Behalf Of *Stewart 
> Bryant
> *Sent:* Tuesday, June 19, 2018 1:19 PM
>
> [Bruno] Agreed. And it can be argued that this creates a state on the 
> ingress. An “outgoing” state, very roughly comparable to Next Hop 
> Label Forwarding Entry (NHLFE))
>
> [Bruno] Adding a Binding SID to this SR policy introduces an 
> “incoming” state, very roughly comparable to Incoming Label Map (ILM). 
> But this gets additional benefit as it allows others SR nodes to use 
> this state/SR policy.
>

The text of course is a direct derivative of the original charter text:

The SPRING working group will define procedures that will allow
a node to steer a packet between any source and destination through
a SPRING region on any path without requiring state to be
maintained by transited nodes, but rather at the source device.

However that pre-dates the introduction of binding SIDs which although 
can be considered a type of shared link are non-the-less state usually 
introduced to overcome a specific limitation in the SR hardware, since 
they achieve nothing that base SR cannot achieve without them.

> At high level, I believe that this is a key distinction of 
> spring/segment routing hence worth keeping in the high level 
> introduction of the WG.
>
> Now do we need to add text about more specific details, such as BSID? 
> I’d rather not, as I don’t see what this would bring. I also don’t 
> think that this sentence prohibits the creation of states when 
> required/useful.
>
I suppose if you replaced:

and without the need for per-path state information to be held at 
transit nodes.

with

with minimum path state introduced at the transit nodes.

that would be closer to the design we have.

- Stewart

---

From: David Allan I <[email-masked]>
Date: Tue, 19 Jun 2018 15:53:03 +0000

Hi

I do not quite get the same warm and fuzzy from the definition when thinking about multicast…..

The mapping of the binding SID to local policy is still IMO per path state. For a simple p2p path it is pretty straightforward as the mapping can be to a common policy abstraction at every node (send to ‘x’) .

In the case of multicast, the mapping would be unique at every node that had state for the binding SID (send copy to ‘a’ and ‘b’, send copy to ‘m’ and ‘q’ etc.) .  So some means of disseminating the mappings is required, and correlating them with the SID.  So the difference between a binding SID and a global SID for multicast IMO is choice of terminology.

So you have to decide if the whole “avoiding per path state” discussion is simply a desirable goal, or a strict admonition.  A bulk overprovisioning model to eliminate per path state will not work for multicast.

Cheers
Dave

From: spring <[email-masked]> On Behalf Of Alexander Vainshtein
Sent: Tuesday, June 19, 2018 6:38 AM
To: [email-masked]; Stewart Bryant <[email-masked]>
Cc: SPRING WG List <[email-masked]>; Rob Shakir <robjs=[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Bruno, Stewart and all,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, June 19, 2018 3:38 PM
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG List <[email-masked]<mailto:[email-masked]>>; Rob Shakir <robjs=[email-masked]<mailto:robjs=[email-masked]>>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Stewart,

- Stewart

Thank you.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 19 Jun 2018 17:07:53 +0100

Yes, I agree.

- S

On 19/06/2018 16:53, David Allan I wrote:
> The mapping of the binding SID to local policy is still IMO per path 
> state. For a simple p2p path it is pretty straightforward as the 
> mapping can be to a common policy abstraction at every node (send to 
> ‘x’) .
>
> In the case of multicast, the mapping would be unique at every node 
> that had state for the binding SID (send copy to ‘a’ and ‘b’, send 
> copy to ‘m’ and ‘q’ etc.) .  So some means of disseminating the 
> mappings is required, and correlating them with the SID.  So the 
> difference between a binding SID and a global SID for multicast IMO is 
> choice of terminology.
>
> So you have to decide if the whole “avoiding per path state” 
> discussion is simply a desirable goal, or a strict admonition.  A bulk 
> overprovisioning model to eliminate per path state will not work for 
> multicast.
>
> Cheers
>
> Dave
>
> *From:*spring <[email-masked]> *On Behalf Of *Alexander 
> Vainshtein
> *Sent:* Tuesday, June 19, 2018 6:38 AM
> *To:* [email-masked]; Stewart Bryant <[email-masked]>
> *Cc:* SPRING WG List <[email-masked]>; Rob Shakir 
> <robjs=[email-masked]>
> *Subject:* Re: [spring] Updating the SPRING WG Charter
>
> Bruno, Stewart and all,
>
> I have looked up Section 5 “*/Binding Segment/*” of the Segment 
> Routing Architecture 
> <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15>draft, 
> and it says:
>
> From my POV this definition is fully aligned both with the Bruno’s 
> last email and with my earlier argument why a BSID does not add a 
> */per-path state/* in the transit nodes.
>
> Regards,
>
> Sasha
>
> Office: +972-39266302
>
> Cell: +972-549266302
>
> <mailto:[email-masked]>
>
> *From:*spring [mailto:[email-masked]] *On Behalf Of 
> [email-masked] <mailto:[email-masked]>
> *Sent:* Tuesday, June 19, 2018 3:38 PM
> *To:* Stewart Bryant <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* SPRING WG List <[email-masked] <mailto:[email-masked]>>; Rob 
> Shakir <robjs=[email-masked] 
> <mailto:robjs=[email-masked]>>
> *Subject:* Re: [spring] Updating the SPRING WG Charter
>
> Hi Stewart,
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 20 Jun 2018 06:40:09 +0000

Hi Ruediger,

Sorry for the late reply, I missed your below mail and just find it when doing some mail filtering today.

SR aims to remove the per-path state from the core of the network. Per-segment state is still needed by all routers in the SR domain. You are correct that “Using SR as the mechanism to identify sets of resources” may introduce additional per-segment state, but no per-path state will be introduced. In my understanding this aligns with the SR paradigm thus can be part of the SPRING charter.

Best regards,
Jie

发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2018年6月13日 21:17
收件人: Dongjie (Jimmy) <[email-masked]>
抄送: [email-masked]
主题: AW: [spring] Updating the SPRING WG Charter

Dear Ji,

Regards,

Ruediger

An: [email-masked]<mailto:[email-masked]>; Zafar Ali (zali) <zali=[email-masked]<mailto:zali=[email-masked]>>

Dear Zafar,

Best regards,
Jie

Dear Zafar,

Dear Rob, Bruno,

Regards,
--Bruno

Thanks

Regards … Zafar

Hi SPRING,

Thanks,
Bruno & Rob

Thank you.

---

From: <[email-masked]>
Date: Thu, 28 Jun 2018 12:51:43 +0000

Hi SPRING,

Following the discussion on the mailing list, please find below the updated text.
The plan is to send it to Martin end of this week.

The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6). SPRING WG serves as a forum to discuss SPRING networks operations, define new applications, and specify extensions of Segment Routing technologies.

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 and without the need for per-path state information to be held at transit nodes. Full explicit control (through loose or strict path specification) can be achieved in a network comprising only SPRING nodes, however SPRING nodes must inter-operate through loose routing in existing networks and may find it advantageous to use loose routing for other network applications.

The scope of the SPRING WG work includes both single Autonomous System (AS) and multi-AS environments. Segment Routing operates within a trusted domain; as described in the architecture, a node imposing a segment list is assumed to be allowed to do so. Nonetheless, the SPRING WG must strive to identify and address security considerations brought up by the technologies it defines.
The technologies SPRING WG defines may be applicable to both centralised and distributed path computation.

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 will manage its specific work items by milestones agreed with the responsible Area Director.

The work-items of the SPRING WG include functional specifications for:
o Segment Routing policies and the associated steering, signalling and traffic engineering mechanisms.

o SRv6 network programming for the underlay networks and overlay services, and including data plane behavior and functions associated with SIDs

o Operation, Administration and Management (OAM), and traffic accounting in networks with SR-MPLS and SRv6 data planes in the case where SR introduces specificities compared to MPLS or IPv6 technologies.

o Performance Management (PM) and monitoring in networks with SR-MPLS and SRv6 data planes in the case where SR introduces specificities compared to MPLS or IPv6 technologies.

o Inter-working between SRv6 and SR-MPLS  and between SR and existing routing solutions to allow for seamless deployment and co-existence..

o new types of segments mapping to forwarding behavior  (e.g. local ingress replication, local forwarding resources, a pre-existing replication structure) if needed for new usages.

The work-items of SPRING WG also include:
o Specification of management models (YANG) for Segment Routing applications, services and networks with SR-MPLS and SRv6 dataplanes.

    * IDR for BGP extensions
    * sfc on service chaining applications
    * rtgwg on fast-reroute technologies

Thanks,
Rob, Bruno

From: spring [mailto:[email-masked]] On Behalf Of Rob Shakir
Sent: Friday, June 01, 2018 6:06 PM
To: SPRING WG List
Subject: [spring] Updating the SPRING WG Charter

Hi SPRING,

Thanks,
Bruno & Rob

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 28 Jun 2018 13:21:26 +0000

Bruno and all,
At the first glance looks just fine to me!

Thumb typed by Sasha Vainshtein

________________________________
From: spring <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Thursday, June 28, 2018 3:51:43 PM
To: SPRING WG List
Subject: Re: [spring] Updating the SPRING WG Charter

Hi SPRING,

Thanks,
Rob, Bruno

Hi SPRING,

Thanks,
Bruno & Rob

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 28 Jun 2018 16:18:12 +0000

Bruno,

Many thanks for the updated charter. All look good except one minor wording change for the bullet:

You have:

We think it should be:
o Inter-working between SRv6 and SR-MPLS/LegacyNetwork  and between SR and existing routing solutions to allow for seamless deployment and co-existence..

Because it is very likely that flows might traverse some segment of legacy network (like IPv4) before reaching SRv6 domain. After all, it is not like to expect all network to be IPv6 from Day 1.

Sincerely hope you can add those minor wording to the bullet.

Linda Dunbar

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, June 28, 2018 7:52 AM
To: SPRING WG List <[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi SPRING,

Thanks,
Rob, Bruno

Hi SPRING,

Thanks,
Bruno & Rob

Thank you.

---

From: <[email-masked]>
Date: Fri, 29 Jun 2018 06:02:07 +0000

Hi Bruno,

thanks, looks good to me.

Regards, Ruediger

Von: spring [mailto:[email-masked]] Im Auftrag von [email-masked]
Gesendet: Donnerstag, 28. Juni 2018 14:52
An: SPRING WG List <[email-masked]>
Betreff: Re: [spring] Updating the SPRING WG Charter

Hi SPRING,

Thanks,
Rob, Bruno

Hi SPRING,

Thanks,
Bruno & Rob

Thank you.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 29 Jun 2018 08:33:12 +0000

Hi Bruno,

The updated charter text looks good to me. Thanks.

For the work item “new types of segments mapping to forwarding behavior  (e.g. local ingress replication, local forwarding resources, a pre-existing replication structure) if needed for new usages.”,  the enhanced VPN drafts has been proposed and discussed in previous meetings targeting at the requirements of network slicing, which is a widely accepted use case in many communities. Hope we could make good progress in this work item in SPRING.

Best regards,
Jie

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, June 28, 2018 8:52 PM
To: SPRING WG List <[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi SPRING,

Thanks,
Rob, Bruno

Hi SPRING,

Thanks,
Bruno & Rob

Thank you.

---

From: <[email-masked]>
Date: Fri, 29 Jun 2018 13:49:43 +0000

Hi Jie,

Thanks for the feedback.

Just for clarification, this work item allows for the definition of new type of segments, especially since the SPRING WG seems the right home to discuss this.
It’s not a statement that spray, or enhanced QoS/VPN, or any specific individual draft will be adopted by the WG.

Thanks,
Best regards,
--Bruno

From: Dongjie (Jimmy) [mailto:[email-masked]]
Sent: Friday, June 29, 2018 10:33 AM
To: DECRAENE Bruno IMT/OLN; SPRING WG List
Subject: RE: [spring] Updating the SPRING WG Charter

Hi Bruno,

Best regards,
Jie

Hi SPRING,

Thanks,
Rob, Bruno

Hi SPRING,

Thanks,
Bruno & Rob

Thank you.

---

From: <[email-masked]>
Date: Fri, 29 Jun 2018 13:56:17 +0000

Linda,

Thanks for the feedback.

From: Linda Dunbar [mailto:[email-masked]]
Sent: Thursday, June 28, 2018 6:18 PM
To: DECRAENE Bruno IMT/OLN; SPRING WG List
Subject: RE: [spring] Updating the SPRING WG Charter

Bruno,

You have:

We think it should be:

[Bruno] I though this point would be covered by Inter-working […] between SR and existing routing solutions to allow for seamless deployment and co-existence
Am I missing something? Or would you have something specific in mind?

--Bruno

Linda Dunbar

Hi SPRING,

Thanks,
Rob, Bruno

Hi SPRING,

Thanks,
Bruno & Rob

Thank you.

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 29 Jun 2018 15:04:42 +0000

Bruno,

IMHO, “Interworking between SR and Legacy Networks” is more appropriate than “Interworking between SR and existing routing solutions” because “Interworking SR with existing routing solutions” can imply needing changes to the “existing routing solutions”.

Linda

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 29, 2018 8:56 AM
To: Linda Dunbar <[email-masked]>
Cc: SPRING WG List <[email-masked]>
Subject: RE: [spring] Updating the SPRING WG Charter

Linda,

Thanks for the feedback.

Bruno,

You have:

We think it should be:

--Bruno

Linda Dunbar

Hi SPRING,

Thanks,
Rob, Bruno

Hi SPRING,

Thanks,
Bruno & Rob

Thank you.

Thank you.

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 29 Jun 2018 11:19:41 -0400

Linda,

“Legacy Networks” is a derogatory term used by OF bigots to call anything, that’s  distributed ☺

There’s nothing wrong with changing and evolving existing networking to be more programmable and flexible, changes are welcome.

I don’t think we should call existing networking – “Legacy”.

Cheers,

Jeff

From: spring <[email-masked]> on behalf of Linda Dunbar <[email-masked]>
Date: Friday, June 29, 2018 at 11:05
To: "[email-masked]" <[email-masked]>
Cc: SPRING WG List <[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Bruno, 

Linda

Linda,

Thanks for the feedback.

Bruno, 

You have:

We think it should be:

--Bruno

Linda Dunbar

Hi SPRING,

 

    * IDR for BGP extensions

 

Thanks,

Rob, Bruno

Hi SPRING,

 

  mechanisms.

  IPv6 technologies.

        * idr for BGP extensions

Thanks,

Bruno & Rob

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 29 Jun 2018 15:25:47 +0000

How about “Interworking SR with existing networks”?

Linda

From: Jeff Tantsura [mailto:[email-masked]]
Sent: Friday, June 29, 2018 10:20 AM
To: Linda Dunbar <[email-masked]>; [email-masked]
Cc: SPRING WG List <[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Linda,

Cheers,
Jeff
From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Friday, June 29, 2018 at 11:05
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Updating the SPRING WG Charter

Bruno,

Linda

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, June 29, 2018 8:56 AM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG List <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] Updating the SPRING WG Charter

Linda,

Thanks for the feedback.

Bruno,

You have:

We think it should be:

--Bruno

Linda Dunbar

Hi SPRING,

Thanks,
Rob, Bruno

Hi SPRING,

Thanks,
Bruno & Rob

Thank you.

Thank you.

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 29 Jun 2018 12:17:13 -0400

Hi Bruno/Rob,

Looks good, well done!

Cheers,

Jeff

From: spring <[email-masked]> on behalf of <[email-masked]>
Date: Thursday, June 28, 2018 at 08:52
To: SPRING WG List <[email-masked]>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi SPRING,

 

    * IDR for BGP extensions

 

Thanks,

Rob, Bruno

Hi SPRING,

 

  mechanisms.

  IPv6 technologies.

        * idr for BGP extensions

Thanks,

Bruno & Rob