Re: [spring] SPRING - rechartering discussion

[Loa Andersson]

Martin,

I think we fully agree!

/Loa

On 2018-03-20 13:37, Martin Horneffer wrote:

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:


Martin H,

On 2018-03-18 00:19, Martin Horneffer wrote:

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.


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 Anderssonemail: l...@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting phone: +46 739 81 21 64

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] SPRING - rechartering discussion

[Martin Horneffer]

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:


Martin H,

On 2018-03-18 00:19, Martin Horneffer wrote:

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.


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



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] SPRING - rechartering discussion

[Ruediger.Geib]

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:spring-boun...@ietf.org] Im Auftrag von Zafar Ali (zali)
Gesendet: Sonntag, 18. März 2018 03:11
An: Martin Horneffer <m...@nic.dtag.de>; spring-cha...@ietf.org
Cc: spring@ietf.org; martin.vigour...@nokia.com; Alvaro Retana 
<aretana.i...@gmail.com>
Betreff: Re: [spring] SPRING - rechartering discussion

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" 
<spring-boun...@ietf.org on behalf of m...@nic.dtag.de> wrote:

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.


 

Re: [spring] SPRING - rechartering discussion

[Adrian Farrel]

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:spring-boun...@ietf.org] On Behalf Of Mach Chen
Sent: 19 March 2018 06:48
To: Zafar Ali (zali); Martin Horneffer; spring-cha...@ietf.org
Cc: spring@ietf.org; martin.vigour...@nokia.com; Alvaro Retana 
Subject: Re: [spring] SPRING - rechartering discussion
 

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,spring-cha...@ietf.org,
抄 送：spring@ietf.org,martin.vigour...@nokia.com,Alvaro Retana,
时间：2018-03-18 02:12:03
主 题：Re: [spring] SPRING - rechartering discussion
 
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" 
<spring-boun...@ietf.org on behalf of m...@nic.dtag.de> wrote:

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, Marti

Re: [spring] SPRING - rechartering discussion

[Loa Andersson]

Martin H,

On 2018-03-18 00:19, Martin Horneffer wrote:

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.


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 Anderssonemail: l...@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting phone: +46 739 81 21 64

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] SPRING - rechartering discussion

[Mach Chen]

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,spring-cha...@ietf.org,
抄 送：spring@ietf.org,martin.vigour...@nokia.com,Alvaro Retana,
时间：2018-03-18 02:12:03
主 题：Re: [spring] SPRING - rechartering discussion

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" 
<spring-boun...@ietf.org on behalf of m...@nic.dtag.de> wrote:

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 bruno.decra...@orange.com:
> 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 h

Re: [spring] SPRING - rechartering discussion

[Jeff Tantsura]

Hi,

I'm not going to repeat all the valid reasons to continue mentioned beforehand.
There's definitely work to be done in architecture and O areas as well as 
co-ordination of various activities across IETF. 

Cheers,
Jeff
On 3/18/18, 13:23, "spring on behalf of Bernier, Daniel" 
<spring-boun...@ietf.org on behalf of daniel.bern...@bell.ca> wrote:

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 <spring-boun...@ietf.org> on behalf of 
bruno.decra...@orange.com <bruno.decra...@orange.com>
Sent: Monday, March 5, 2018 11:59 AM
To: spring@ietf.org
Cc: Alvaro Retana (aretana); spring-cha...@ietf.org
    Subject: [spring] SPRING - rechartering discussion

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:martin.vigour...@nokia.com]
 > Sent: Wednesday, March 29, 2017 4:25 PM
 > To: spring@ietf.org
 > Cc: spring-cha...@ietf.org; 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

Re: [spring] SPRING - rechartering discussion

[Bernier, Daniel]

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 <spring-boun...@ietf.org> on behalf of bruno.decra...@orange.com 
<bruno.decra...@orange.com>
Sent: Monday, March 5, 2018 11:59 AM
To: spring@ietf.org
Cc: Alvaro Retana (aretana); spring-cha...@ietf.org
Subject: [spring] SPRING - rechartering discussion

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:martin.vigour...@nokia.com]
 > Sent: Wednesday, March 29, 2017 4:25 PM
 > To: spring@ietf.org
 > Cc: spring-cha...@ietf.org; 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 em

Re: [spring] SPRING - rechartering discussion

[Leddy, John]

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"  wrote:

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 bruno.decra...@orange.com:
> 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:martin.vigour...@nokia.com]
>   > Sent: Wednesday, March 29, 2017 4:25 PM
>   > To: spring@ietf.org
>   > Cc: spring-cha...@ietf.org; 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 

Re: [spring] SPRING - rechartering discussion

[Ketan Talaulikar (ketant)]

Hi Rob/All,



I would like to re-affirm what Paul, Martin and others have mentioned and there 
are significant milestones that SPRING WG needs to meet in the spirit of the 
charter.



Specifically, I would like to point out the documents related to SR-TE that are 
being worked including its aspects related to OAM, BFD and performance 
monitoring. I would also like to call to attention that 
https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing-policy/ 
is going to be presented at SPRING WG later this week which is the result of 
collaboration between multiple vendors and operators over the last couple of 
years. Multi-vendor deployments are being worked on (as has been shared by 
others on the list). The authors of this draft (including myself) are planning 
to request for WG adoption for this draft here in London.



The SPRING charter milestones were set way back in 2013 when the WG was formed 
and rightly focussed on the initial high level deliverables. We are still in 
the process of producing specifications for SR-TE and the IPv6 data-plane 
instantiation. There are still operational aspects like OAM, YANG, performance 
monitoring, etc. that are being addressed. The SPRING charter also talks about 
virtualization and partitioning of network resources - something that the WG 
has started working on in the form of individual drafts.



IMHO we need to brainstorm on the mailer and when we meet in London on the 
definition of milestones that reflect these work items.



I would also note that SPRING is not a protocol but more of an 
architecture/framework. The charter clearly reflects that we do not work here 
on extensions of existing control plane protocols to achieve SPRING use-cases – 
those are in individual protocol working groups and there are multiple protocol 
flavour options. However, the SPRING WG itself needs to define these 
frameworks/architecture and deliver those documents which would provide context 
for the protocol extensions and enable multi-vendor deployments. Additionally 
SPRING needs to review the work related to these architecture/frameworks and 
use-cases coming from the individual protocol WGs.



I see a good amount of milestones and also the interest to work on them in the 
WG in the spirit of the charter.



Thanks,

Ketan


From: spring <spring-boun...@ietf.org> On Behalf Of Rob Shakir
Sent: 17 March 2018 18:28
To: Zafar Ali (zali) <z...@cisco.com>
Cc: Paul Mattes <pamat...@microsoft.com>; bruno.decra...@orange.com; 
spring@ietf.org; spring-cha...@ietf.org; Alvaro Retana <aretana.i...@gmail.com>
Subject: Re: [spring] SPRING - rechartering discussion

[-Alvaro's Cisco address, +Alvaro's new address]
On Sat, Mar 17, 2018 at 6:26 PM Rob Shakir 
<ro...@google..com<mailto:ro...@google.com>> wrote:
Paul, Zafar,

Thanks for the input. It's good to see this discussed on the list such that we 
can use this as input to the discussion on Friday.

Clearly, use of SR/SPRING is something that the current charter discusses, but 
we do not have specific milestones that define the outcomes that the WG should 
be working towards. I wonder if you have specific proposed milestones that we 
should carry for this work. Particularly, what does SPRING need to publish for 
TE? Is it simply an architecture for traffic engineering work (that can support 
and/or motivate the work that is being developed in other WGs), or are there 
specific other areas that should be covered?

Thanks,
r.

On Sat, Mar 17, 2018 at 8:20 AM Zafar Ali (zali) 
<z...@cisco.com<mailto:z...@cisco.com>> wrote:
Dear WG Chairs,

I fully agree with Paul. Indeed, SRTE is one of the most basic but important 
use-cases of SR. As a matter of fact, SRTE is integral pieces of the SR 
Architecture. It should be considered as part of the core SR Architecture 
definition.

Given this, I am not surprised that currently approved SPRING charter, 
https://datatrackr.ietf.org/doc/charter-ietf-spring/ already fully covers it. I 
am copying text from the current charter text. "The ability for a node to 
specify a forwarding path, other than the normal shortest path, that a 
particular packet
will traverse, benefits a number of network functions, for example:
•   Some types of network virtualization, including multi-topology networks 
and the partitioning of network resources for VPNs
•   Network path and node protection such as fast re-route
•   Network programmability
•   New OAM techniques
•   Simplification and reduction of network signaling components
•   Load balancing and traffic engineering"

Given this, the work Paul pointed out fall in the current deliverables for the 
WG or if needed a new milestone should be added - it's already well within the 
current charter.

Thanks

Regards … Zafar

On 3/16/18, 3:13 PM, "spring on behalf of Paul Mattes" 
<spring-boun...@ietf.org<mailto:spring-boun...@ietf.org> on behalf 

Re: [spring] SPRING - rechartering discussion

[Gaurav Dawra]

+ Alvaro’s right email id 

Sent from my iPhone

> On Mar 18, 2018, at 2:18 AM, Gaurav Dawra  wrote:
> 
> I echo Paul and Daniel’s comments and add following:
> 
>   .SR-TE is an critical piece of technology to do Traffic Engineering and 
> optimal steering and utilization of resources.
>   . SR-MPLS/SRv6 inter-op is important for any operator to integrate multiple 
> islands together. There has been some initial effort integrate these together 
> to be able to do end-to-end SR-TE based steering. More effort is needed to 
> standardize these initiatives and  Need to document clear set of operator 
> optimal solutions.
>. Close collaboration with DC initiatives to integrate SR-TE. Again, there 
> are some early stage few proposals in pipeline and close collaboration of 
> this WG will be needed to standardize these efforts.
>. To enable any scalable optimal solution - Control plane and data plane 
> extension associated with an SRv6 SID (EVPN, BGPLS, ISIS, OSFP, PCEP etc) are 
> needed and there are proposals in pipeline. Effort from this WG will be 
> needed to optimally standardize these extensions.
> 
> Cheers,
> 
> Gaurav Dawra
> 
> Sent from my iPhone
> 
>> On Mar 18, 2018, at 12:05 AM, Voyer, Daniel  wrote:
>> 
>> I have to echo Paul’s comments and add the following:
>> 
>> 1. So far, we haven’t worked yet on SRv6 and SR-MPLS interworking. This is a 
>> necessity for any operators trying to integrate and leverage SR for 
>> different islands in its network; wireline AND packet core – Mobile network. 
>> Traffic engineering is obviously a key benefice for both SRv6 & SR-MPLS, but 
>> needs more work for interrupt.
>> 2. Also, some work has been started for addressing multicast with SR, i.e, 
>> TreeSID (SR-MPLS) and SRv6 spray – we need more work to standardize these 
>> initiative in the industry.
>> 
>> Dan Voyer
>> 
>> On 2018-03-16, 3:13 PM, "spring on behalf of Paul Mattes" 
>>  wrote:
>> 
>>   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: bruno.decra...@orange.com  
>>   Sent: Monday, March 5, 2018 11:00 AM
>>   To: spring@ietf.org
>>   Cc: spring-cha...@ietf.org; Alvaro Retana (aretana) 
>>   Subject: SPRING - rechartering discussion
>> 
>>   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:martin.vigour...@nokia.com]
>>> Sent: Wednesday, March 29, 2017 4:25 PM  > To: spring@ietf.org  > Cc: 
>>> spring-cha...@ietf.org; 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 

Re: [spring] SPRING - rechartering discussion

[Gaurav Dawra]

I echo Paul and Daniel’s comments and add following:

   .SR-TE is an critical piece of technology to do Traffic Engineering and 
optimal steering and utilization of resources.
   . SR-MPLS/SRv6 inter-op is important for any operator to integrate multiple 
islands together. There has been some initial effort integrate these together 
to be able to do end-to-end SR-TE based steering. More effort is needed to 
standardize these initiatives and  Need to document clear set of operator 
optimal solutions.
. Close collaboration with DC initiatives to integrate SR-TE. Again, there 
are some early stage few proposals in pipeline and close collaboration of this 
WG will be needed to standardize these efforts.
. To enable any scalable optimal solution - Control plane and data plane 
extension associated with an SRv6 SID (EVPN, BGPLS, ISIS, OSFP, PCEP etc) are 
needed and there are proposals in pipeline. Effort from this WG will be needed 
to optimally standardize these extensions.

Cheers,

Gaurav Dawra

Sent from my iPhone

> On Mar 18, 2018, at 12:05 AM, Voyer, Daniel  wrote:
> 
> I have to echo Paul’s comments and add the following:
> 
> 1. So far, we haven’t worked yet on SRv6 and SR-MPLS interworking. This is a 
> necessity for any operators trying to integrate and leverage SR for different 
> islands in its network; wireline AND packet core – Mobile network. Traffic 
> engineering is obviously a key benefice for both SRv6 & SR-MPLS, but needs 
> more work for interrupt.
> 2. Also, some work has been started for addressing multicast with SR, i.e, 
> TreeSID (SR-MPLS) and SRv6 spray – we need more work to standardize these 
> initiative in the industry.
> 
> Dan Voyer
> 
> On 2018-03-16, 3:13 PM, "spring on behalf of Paul Mattes" 
>  wrote:
> 
>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: bruno.decra...@orange.com  
>Sent: Monday, March 5, 2018 11:00 AM
>To: spring@ietf.org
>Cc: spring-cha...@ietf.org; Alvaro Retana (aretana) 
>Subject: SPRING - rechartering discussion
> 
>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:martin.vigour...@nokia.com]
>> Sent: Wednesday, March 29, 2017 4:25 PM  > To: spring@ietf.org  > Cc: 
>> spring-cha...@ietf.org; 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  > 

Re: [spring] SPRING - rechartering discussion

[Zafar Ali (zali)]

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" 
 wrote:

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 bruno.decra...@orange.com:
> 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 

Re: [spring] SPRING - rechartering discussion

[Martin Horneffer]

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 bruno.decra...@orange.com:

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:martin.vigour...@nokia.com]
  > Sent: Wednesday, March 29, 2017 4:25 PM
  > To: spring@ietf.org
  > Cc: spring-cha...@ietf.org; 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 

Re: [spring] SPRING - rechartering discussion

[Voyer, Daniel]

I have to echo Paul’s comments and add the following:

1. So far, we haven’t worked yet on SRv6 and SR-MPLS interworking. This is a 
necessity for any operators trying to integrate and leverage SR for different 
islands in its network; wireline AND packet core – Mobile network. Traffic 
engineering is obviously a key benefice for both SRv6 & SR-MPLS, but needs more 
work for interrupt.
2. Also, some work has been started for addressing multicast with SR, i.e, 
TreeSID (SR-MPLS) and SRv6 spray – we need more work to standardize these 
initiative in the industry.

Dan Voyer

On 2018-03-16, 3:13 PM, "spring on behalf of Paul Mattes" 
 wrote:

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: bruno.decra...@orange.com  
Sent: Monday, March 5, 2018 11:00 AM
To: spring@ietf.org
Cc: spring-cha...@ietf.org; Alvaro Retana (aretana) 
Subject: SPRING - rechartering discussion

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:martin.vigour...@nokia.com]
 > Sent: Wednesday, March 29, 2017 4:25 PM  > To: spring@ietf.org  > Cc: 
spring-cha...@ietf.org; 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 

Re: [spring] SPRING - rechartering discussion

[Zafar Ali (zali)]

Dear WG Chairs, 

I fully agree with Paul. Indeed, SRTE is one of the most basic but important 
use-cases of SR. As a matter of fact, SRTE is integral pieces of the SR 
Architecture. It should be considered as part of the core SR Architecture 
definition. 

Given this, I am not surprised that currently approved SPRING charter, 
https://datatrackr.ietf.org/doc/charter-ietf-spring/ already fully covers it. I 
am copying text from the current charter text. "The ability for a node to 
specify a forwarding path, other than the normal shortest path, that a 
particular packet 
will traverse, benefits a number of network functions, for example:
•   Some types of network virtualization, including multi-topology networks 
and the partitioning of network resources for VPNs
•   Network path and node protection such as fast re-route
•   Network programmability
•   New OAM techniques
•   Simplification and reduction of network signaling components
•   Load balancing and traffic engineering"

Given this, the work Paul pointed out fall in the current deliverables for the 
WG or if needed a new milestone should be added - it's already well within the 
current charter.

Thanks
 
Regards … Zafar 
 
On 3/16/18, 3:13 PM, "spring on behalf of Paul Mattes" 
 wrote:

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: bruno.decra...@orange.com  
Sent: Monday, March 5, 2018 11:00 AM
To: spring@ietf.org
Cc: spring-cha...@ietf.org; Alvaro Retana (aretana) 
Subject: SPRING - rechartering discussion

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:martin.vigour...@nokia.com]
 > Sent: Wednesday, March 29, 2017 4:25 PM  > To: spring@ietf.org  > Cc: 
spring-cha...@ietf.org; 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  

Re: [spring] SPRING - rechartering discussion

[Paul Mattes]

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: bruno.decra...@orange.com  
Sent: Monday, March 5, 2018 11:00 AM
To: spring@ietf.org
Cc: spring-cha...@ietf.org; Alvaro Retana (aretana) 
Subject: SPRING - rechartering discussion

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:martin.vigour...@nokia.com]
 > Sent: Wednesday, March 29, 2017 4:25 PM  > To: spring@ietf.org  > Cc: 
 > spring-cha...@ietf.org; 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.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] SPRING - rechartering discussion

[bruno.decraene]

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:martin.vigour...@nokia.com]
 > Sent: Wednesday, March 29, 2017 4:25 PM
 > To: spring@ietf.org
 > Cc: spring-cha...@ietf.org; 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.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring