Subject: Re: [spring] SPRING - rechartering discussion

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sat, 17 Mar 2018 08:20:25 +0000

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" <[email-masked] on behalf of [email-masked]> 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: [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,
    
    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.
    
    _______________________________________________
    spring mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/spring

---

From: Rob Shakir <[email-masked]>
Date: Sat, 17 Mar 2018 18:26:01 +0000

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) <[email-masked]> 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
> •       Some types of network virtualization, including multi-topology
> networks and the partitioning of network resources for VPNs
> 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" <
> [email-masked] on behalf of [email-masked]> 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
>
>     Cc: [email-masked]; Alvaro Retana (aretana) <[email-masked]
> >
>     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.
>
>     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).
>      * 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
>      > 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.
>      >
>      > 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.

---

From: Rob Shakir <[email-masked]>
Date: Sat, 17 Mar 2018 18:28:27 +0000

[-Alvaro's Cisco address, +Alvaro's new address]

On Sat, Mar 17, 2018 at 6:26 PM Rob Shakir <[email-masked]> 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.
>
>> 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
>> 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
>>      last meeting there were proposals discussed in SPRING to realize
>> some form of service chaining. any work in that space would require close
>>      > There are also a few individual documents knocking at the door,
>> and some  > of them were presented during the session.
>>      >
>>     If you have received this email in error, please notify the sender
>> and delete this message and its attachments.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sun, 18 Mar 2018 07:42:21 +0000

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 <[email-masked]> On Behalf Of Rob Shakir
Sent: 17 March 2018 18:28
To: Zafar Ali (zali) <[email-masked]>
Cc: Paul Mattes <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Alvaro Retana <[email-masked]>
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 <robjs@google..com<mailto:[email-masked]>> 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) <[email-masked]<mailto:[email-masked]>> wrote:
Dear WG Chairs,

Thanks

Regards … Zafar

On 3/16/18, 3:13 PM, "spring on behalf of Paul Mattes" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

            pdm

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

    Hello WG,

     * service chaining

     * yang

    Thank you,
    --Martin, Rob, Bruno

     > From: Martin Vigoureux [mailto:[email-masked]<mailto:[email-masked]>]
     > Sent: Wednesday, March 29, 2017 4:25 PM  > To: [email-masked]<mailto:[email-masked]>  > Cc: [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana)  > Subject: Next steps for SPRING?
     >
     > WG,
     >
     > There are also a few individual documents knocking at the door, and some  > of them were presented during the session..
     >

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