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"
<spring-boun...@ietf.org on behalf of pamat...@microsoft.com> 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 <bruno.decra...@orange.com>
Sent: Monday, March 5, 2018 11:00 AM
To: spring@ietf.org
Cc: spring-cha...@ietf.org; Alvaro Retana (aretana) <aret...@cisco.com>
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 mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
