Subject: [spring] SPRING - rechartering discussion

From: <[email-masked]>
Date: Mon, 5 Mar 2018 16:59:41 +0000

Hello WG,
 
now that nearly all the core documents are in the hands of IESG or beyond, we think it is time to (re)discuss rechartering.
We brought up that question few meetings ago and the feedback, at that  time, was that the WG at least needs to be maintained to discuss the extensions following deployment feedback.

But we need also identify technical directions.
 
In order to initiate the discussion we are proposing some high level items but we'd like to make clear a few points before:
 * these are only proposals; what might end-up as the next steps for SPRING will be what the WG is willing to work on (which includes having cycles for that).
 * what the WG might be rechartered to do is not necessarily limited to that; so other proposals are welcome.
 
 So, we thought of the following:
 
 * general architectural work / extensions
 there are still few items on our plate and we expect that some might need to be progressed, and we should maybe allow for others to come.
 
 * service chaining
 last meeting there were proposals discussed in SPRING to realize some form of service chaining. any work in that space would require close coordination with SFC and maybe other WG.
 
 * yang
 we are a bit behind here and there is definitely work to do.

So please comment on these and propose additional items.

We'll likely have a dedicated slot in London but we'd like to progress before that.

Thank you,
--Martin, Rob, Bruno

 > -----Original Message-----
 > From: Martin Vigoureux [mailto:[email-masked]]
 > Sent: Wednesday, March 29, 2017 4:25 PM
 > To: [email-masked]
 > Cc: [email-masked]; Alvaro Retana (aretana)
 > Subject: Next steps for SPRING?
 > 
 > WG,
 > 
 > in the session we have opened the discussion on the future of the WG,
 > putting all options on the table (recharter/close/sleep).
 > As a foreword, we still have few WG Documents that we need to -and will-
 > push towards IESG (and a greater number that need to reach RFC status),
 > but with those we'll have reached most if not all of our milestones,
 > thus the question on what's next.
 > 
 > So, we think we have heard during the session that closing wasn't
 > desired and one reason for that is to have a home to share and discuss
 > deployment considerations as the technology gets deployed.
 > There are also a few individual documents knocking at the door, and some
 > of them were presented during the session.
 > 
 > To reach out to everyone, we are thus asking the question on the list.
 > We would like to hear from you all what the working group should be
 > focussing on.
 > 
 > Note, the expectation is that future items should not be use-cases but
 > rather be technology extensions/evolutions.
 > 
 > Thank you
 > 
 > Martin & Bruno

_________________________________________________________________________________________________________________________

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: Paul Mattes <[email-masked]>
Date: Fri, 16 Mar 2018 19:12:51 +0000

I feel it is essential that the SPRING WG continues and extends its work, and remains the locus of activity on segment routing issues. In particular, the work on segment routing traffic engineering (SR-TE) has reached a critical point, both in terms of the standards work and our (Microsoft's) application of it, and anything that might cause the effort to lose focus would be a mistake. Traffic engineering should be a specific milestone for the WG going forward.

        pdm

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Monday, March 5, 2018 11:00 AM
To: [email-masked]
Cc: [email-masked]; Alvaro Retana (aretana) <[email-masked]>
Subject: SPRING - rechartering discussion

Hello WG,

 * general architectural work / extensions  there are still few items on our plate and we expect that some might need to be progressed, and we should maybe allow for others to come.

 * service chaining

 * yang

Thank you,
--Martin, Rob, Bruno

 > Sent: Wednesday, March 29, 2017 4:25 PM  > To: [email-masked]  > Cc: [email-masked]; Alvaro Retana (aretana)  > Subject: Next steps for SPRING?
 >
 > WG,
 >
 > in the session we have opened the discussion on the future of the WG,  > putting all options on the table (recharter/close/sleep).
 > As a foreword, we still have few WG Documents that we need to -and will-  > push towards IESG (and a greater number that need to reach RFC status),  > but with those we'll have reached most if not all of our milestones,  > thus the question on what's next.
 >
 > So, we think we have heard during the session that closing wasn't  > desired and one reason for that is to have a home to share and discuss  > deployment considerations as the technology gets deployed.
 > There are also a few individual documents knocking at the door, and some  > of them were presented during the session.
 >
 > We would like to hear from you all what the working group should be  > focussing on.
 >
 > Note, the expectation is that future items should not be use-cases but  > rather be technology extensions/evolutions.
 >
 > Thank you
 >
 > Martin & Bruno

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: Martin Horneffer <[email-masked]>
Date: Sun, 18 Mar 2018 01:19:01 +0100

Hello Bruno, Martin, Rob, and whole WG,

as with many bigger protocols that actually make their way into 
production networks, I get the strong feeling that SPRING is not done 
with the conclusion of the core documents. As the technology gets closer 
to production use, unforeseen topics and issues appear that need to be 
discussed and - in many cases - standardized. I do see the need for 
documents of the "operators' requirements" style.

Conflict resolution was one good example. Others are about traffic 
steering and traffic and/or performance measurement und monitoring.

Probably not all networks have the same requirement as ours, but maybe 
there are others that feel like us: we cannot afford to transport 
sginificant huge amounts of traffic if we cannot measure it. Measure it 
in a way that is suitable to generate traffic matrices and and allows to 
offline simulate the whole network.
Same for traffic steering: how can I actually differentiate the traffic 
and have the routers choose the right segment lists for every packet?

While I'm having very good discussions with multiple vendors about these 
topics, I really think this is something that needs to be standardized. 
And in this case it means, in my eyes, that the charter of the SPRING wg 
must be enhanced in some way to allow this kind of discussion and 
standardization.

Best regards, Martin

Am 05.03.18 um 17:59 schrieb [email-masked]:
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sun, 18 Mar 2018 02:11:18 +0000

Dear WG Chairs, 

I completely agree with Martin. To add, the task for "New OAM techniques" is not only explicitly mentioned in the existing charter 
(https://datatracker.ietf.org/doc/charter-ietf-spring/) but there is a current milestone associated with it, "Specify the OAM mechanisms needed to support SPRING." 

At the moment the WG has only defined basic ping, traceroute and probing tools. From the initial deployments experiences of segment routing, SPs are coming up with the new requirements for operation and management, performance monitoring, connectivity verification and traffic accounting, etc. There are numerous individual contributions in this area listed in the following (see https://datatracker.ietf.org/wg/spring/documents/ for detailed list): 

    + draft-ali-spring-sr-traffic-accounting-00. Martin specifically mentioned the requirement for traffic accounting. We requested a presentation slot where we planned to ask for WG adaptation, but due to time constraint, it did not fit the agenda. 
    + draft-hegde-spring-traffic-accounting-for-sr-paths-01 is also addressing requirement outlined by Martin. It was presented at the last IETF and was subject to engaging discussion on the mailing list. 
    + draft-ali-spring-srv6-oam-00 is on Spring WG agenda Friday, and we plan to ask for WG adaptation. 
    + draft-gandhi-spring-sr-mpls-pm-00 requested a slot, but due to time constraint, it did not fit the agenda. 
    + draft-ali-spring-srv6-pm-02 also requested a slot, but due to time constraint, it did not make it to the agenda. 
    + draft-ali-spring-bfd-sr-policy-00 and draft-mirsky-spring-bfd-05 are on Spring agenda for discussion on Friday. 
    + draft-cheng-spring-mpls-path-segment-01
    + draft-fioccola-spring-flow-label-alt-mark-01 
    + draft-li-spring-passive-pm-for-srv6-np-00 

In summary, as you can see that there is a tremendous interest in the SPRING OAM area, which is in the existing charter and a current milestone. I would like to request WG chair to complete this work in the existing milestone or add a new milestone for it. 

Thanks

Regards ... Zafar

On 3/17/18, 8:19 PM, "spring on behalf of Martin Horneffer" <[email-masked] on behalf of [email-masked]> wrote:

    

    Best regards, Martin

---

From: "徐小虎(义先)" <[email-masked]>
Date: Sun, 18 Mar 2018 19:36:34 +0800

Hi all,
I believe the following topics are worthwhile to be considered in SPRING rechartering since they are very imporant to operotors who are deploying SR technologies in their networks:
1) SR-based SFC. SFC in nature is a kind of source routing. Therefore, it's straightforward to consider how to leverage the existing SR technology to achieve SFC, especially in the SR-enabled network environment.
2) SR OAM. OAM is becoming an important feature when SR is being deployed in more and more production networks.
3) SR-assisted SD-WAN. With the SLA capability provided by SR, SD-WAN operators could provide customers a SD-WAN solution with a better performance.
Best regards,Xiaou

------------------------------------------------------------------bruno.decraene <[email-masked]>2018年3月6日(星期二) 00:[email-masked] <[email-masked]>Alvaro Retana (aretana) <[email-masked]>; [email-masked] <[email-masked]>[spring] SPRING - rechartering discussion
Hello WG,

 

 
 * service chaining
 
 * yang

Thank you,
--Martin, Rob, Bruno

 > -----Original Message-----
 > From: Martin Vigoureux [mailto:[email-masked]]
 > Sent: Wednesday, March 29, 2017 4:25 PM
 > To: [email-masked]
 > Cc: [email-masked]; Alvaro Retana (aretana)
 > Subject: Next steps for SPRING?
 > 
 > WG,
 > 
 > in the session we have opened the discussion on the future of the WG,
 > putting all options on the table (recharter/close/sleep).
 > As a foreword, we still have few WG Documents that we need to -and will-
 > push towards IESG (and a greater number that need to reach RFC status),
 > but with those we'll have reached most if not all of our milestones,
 > thus the question on what's next.
 > 
 > So, we think we have heard during the session that closing wasn't
 > desired and one reason for that is to have a home to share and discuss
 > deployment considerations as the technology gets deployed.
 > There are also a few individual documents knocking at the door, and some
 > of them were presented during the session.
 > 
 > To reach out to everyone, we are thus asking the question on the list.
 > We would like to hear from you all what the working group should be
 > focussing on.
 > 
 > Note, the expectation is that future items should not be use-cases but
 > rather be technology extensions/evolutions.
 > 
 > Thank you
 > 
 > Martin & Bruno

---

From: "Leddy, John" <[email-masked]>
Date: Sun, 18 Mar 2018 11:44:31 +0000

Bruno, Martin, Rob,

I wanted to echo Martin's comment that it doesn't feel like SPRING has concluded with core documents in several key areas.

We are looking at several SRv6 based application services where the application and server participate in utilizing the SRH.
How this can be signaled and specified is work that needs to be done, including how it works with different transport protocols.
Having applications actively participate in programing the RH is early, but definitely in the original intent of extension headers.

Best,
John

On 3/18/18, 12:19 AM, "Martin Horneffer" <[email-masked]> wrote:

    

    Best regards, Martin

---

From: "Bernier, Daniel" <[email-masked]>
Date: Sun, 18 Mar 2018 13:23:39 +0000

Hi,

I echo the need to continue the SPRING work on service-chaining. There is a growing interest to have a mechanism that operates at the forwarding plane level using source routing as an alternative to a dedicated service overlay. This will surely generate other related work such as automated service discovery, inter-domain chaining policies, parallelism versus sequential chaining, various control-plane implementations, etc.

Secondly, since there is a tight relation to SR chaining and TE policies, I believe there will is a lot of opportunities related to Path Awareness which is currently running in IRTF. Opportunities like, intent translation to SR policies, Policy requests or announcements between domains and host (probably app) level TE policy requests (e.g. how can an app receive a proper policy based on its requirements) ?

My humble operator 0.02 cents.

Daniel Bernier | Bell Canada
________________________________________
From: spring <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Monday, March 5, 2018 11:59 AM
To: [email-masked]
Cc: Alvaro Retana (aretana); [email-masked]
Subject: [spring] SPRING - rechartering discussion

Hello WG,

 * service chaining

 * yang

Thank you,
--Martin, Rob, Bruno

---

From: Mach Chen <[email-masked]>
Date: Mon, 19 Mar 2018 06:48:07 +0000

Hi all,

I completely agree with Ali and Martin here, OAM is very important tool for a technology to be deployed in a production network, we see more and more requirements in this area. I support the idea to add the  OAM milestone to the new charter.

Best regards,
Mach
发件人：Zafar Ali (zali)
收件人：Martin Horneffer,[email-masked],
抄 送：[email-masked],[email-masked],Alvaro Retana,
时间：2018-03-18 02:12:03
主 题：Re: [spring] SPRING - rechartering discussion

Dear WG Chairs,

Thanks

Regards ... Zafar

    Best regards, Martin

---

From: Loa Andersson <[email-masked]>
Date: Mon, 19 Mar 2018 10:12:41 +0000

Martin H,

> documents of the "operators' requirements" style.

I take that you don't entirely agree with the "core documents almost
done" in the mail that Marin and Bruno sent starting up the
re-chartering discussion. I think I see your point and the things you
point at certainly needs to be addressed.

Sorry if I misunderstand what you are saying. I don't see the "not
completed" as a reason not take the discussion and actually recharter.
Working do this quite often, since more understanding of the area is
gained through the work done, but at the same time we also see a shift
in focus that we need to capture.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 19 Mar 2018 10:49:01 -0000

Yes, OAM, please!
 
There has been some discussion recently about where new SR-related work should be done :-)
 
I wonder whether a task for the WG would be to provide clearer coordination of the related work in other WGs. Maybe that is a "cookbook", maybe it is just a WG wiki. But it seems to me that there is SR work in 10 (count them!) WGs and that is not a recipe for a stable and well-managed technology.
 
Adrian
 
From: spring [mailto:[email-masked]] On Behalf Of Mach Chen
Sent: 19 March 2018 06:48
To: Zafar Ali (zali); Martin Horneffer; [email-masked]
Cc: [email-masked]; [email-masked]; Alvaro Retana 
Subject: Re: [spring] SPRING - rechartering discussion

Hi all,

Best regards,
Mach
发件人：Zafar Ali (zali)
 
Dear WG Chairs, 

Thanks

Regards ... Zafar

    

    

    Best regards, Martin

---

From: <[email-masked]>
Date: Tue, 20 Mar 2018 10:18:59 +0000

Dear WG Chairs,

I agree with Zafar that the OAM topics listed below are of high importance.  Off-list activities on the topics below has been going on for years and the current status is that the first drafts were submitted to IETF Spring WG. From my point of view standardized solutions are preferable to proprietary ones. I think, that Spring WG should pick up and finalise the set of drafts on:
- Traffic Engineering policies for SR domains.
- The set of OAM functions required to support operation of SR domains. 
- The set of OAM functions required to enable and support Traffic Engineering for SR domains. 

This work is not close to being finalized. Further new topics may pop up while the work makes progress.

I support the Spring WG to be maintained and recharted to enable completion of the work mentioned above.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: spring [mailto:[email-masked]] Im Auftrag von Zafar Ali (zali)
Gesendet: Sonntag, 18. März 2018 03:11
An: Martin Horneffer <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; Alvaro Retana <[email-masked]>
Betreff: Re: [spring] SPRING - rechartering discussion

Dear WG Chairs, 

Thanks

Regards ... Zafar

    

    

    Best regards, Martin

---

From: Martin Horneffer <[email-masked]>
Date: Tue, 20 Mar 2018 13:37:17 +0000

Hi Loa,

this looks like some kind of misunderstanding, probably due my 
sloppiness with respect to formal and organizational requirements. I'm 
really sorry for that. My everyday job keeps me busy enough with formal 
requirements, associated tasks, and organizational thinking. Thus I 
really appreciate that other people take care of all that at the IETF.

In other words, I don't in any way oppose a rechartering discussion. All 
I wanted is to say: please let this WG keep going for a while, I really 
think it's needed. And I think it's best done with exactly the group we 
have right now.

If this needs refining or adding milestones, that's fine for me. If it 
requires some rechartering, then ok, too. Just keep the group and allow 
all the mentioned topics to be discussed here.

Best regards, Martin

Am 19.03.18 um 10:12 schrieb Loa Andersson:
>> with the conclusion of the core documents. As the technology gets 
>> closer to production use, unforeseen topics and issues appear that 
>> need to be discussed and - in many cases - standardized. I do see the 
>> need for documents of the "operators' requirements" style.
>

---

From: Loa Andersson <[email-masked]>
Date: Tue, 20 Mar 2018 13:44:15 +0000

Martin,

I think we fully agree!

/Loa

--

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 23 Mar 2018 06:01:14 +0000

Hello SPRING folks,

Let me share an ongoing work in DMM WG that makes SRv6 to be able to provide mobility management path on user plane:

https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane

So please count it when you consider rechartering. But it doesn’t mean that SPRING WG is required to work on mobility management itself. That’s the DMM role.

The SRv6 for mobile user plane draft is going to define SRv6 end function variations to support required mobility user plane functions. For sure that we need responsible authority for SRv6 that review those variations to keep the consistency. So we’d expect that in SPRING WG charter.

Best regards,
--satoru

> 2018/03/05 16:59、[email-masked]:
> 
> Hello WG,
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 23 Mar 2018 11:39:25 +0000

All, 

I agree with Satoru. The Spring WG should be a central place to review the SR related work at DMM and the other WGs. 

Thanks
 
Regards … Zafar 
 
On 3/23/18, 6:01 AM, "spring on behalf of Satoru Matsushima" <[email-masked] on behalf of [email-masked]> wrote:

    Hello SPRING folks,

    

    Best regards,
    --satoru