Subject: Re: [Teas] [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 Mar 2018 00:58:48 +0100

All,

I am not even sure why do we need to discuss applicability of SR-TE to TEAS
WG ... Who started that idea ?

TEAS WG charter states:

" The Traffic Engineering Architecture and Signaling (TEAS) Working
Group is responsible for defining MPLS and GMPLS traffic
engineering architecture ... "

SR TE or for that matter BGP TE (by adjusting BGP policies via BGP
attributes) or OSPF/ISIS TE (by adjusting IGP metrics) have nothing to do
with MPLS or GMPLS. So it should be pretty obvious for those even not very
much skilled with that art that this entire discussion is a classic red
herring and it should be stopped and archived ASAP.

Kind regards,
Robert.

On Wed, Mar 21, 2018 at 12:45 AM, Darren Dukes (ddukes) <[email-masked]>
wrote:

> +1 for Paul, Martin, Dan on SR TE.  I tried to type up something beyond
> what you’ve said, but deleted it…
>
> I think you’ve hit the nail on the head.
>
> As an coder of SR TE Policy, I can confirm that it is as far away from
> RSVP-TE as possible.
>
> Darren
>
>
> On Mar 20, 2018, at 2:45 PM, Paul Mattes <[email-masked]> wrote:
>
> I do not know a great deal about the inner workings of the TEAS WG. I have
> no doubt that the TE activities inside the SPRING WG could benefit from
> close collaboration with TEAS. On the other hand, SR-TE has evolved as a
> quite different approach from the distributed RSVP-TE architecture --
> something that makes it very attractive as a replacement for RSVP-TE in our
> application.
>
> Could the TEAS charter be generalized to include this approach (as it
> would apparently need to be)? Sure. Would separating SR-TE from a WG
> completing a coherent SR architecture help or hinder it? It would hinder
> it, I fear, because it might go from being one of the things that really
> fulfills the promise of SR to being an uncomfortable step-child of a
> broader traffic engineering effort.
>
> (I would love to hear the opposite argument – that many in the TEAS WG
> would like to build on SR-TE policy and its approach as a way to move TE
> forward. Might that be true?)
>
>         *pdm*
>
> *From:* spring <[email-masked]> *On Behalf Of *Voyer, Daniel
> *Sent:* Monday, March 19, 2018 6:42 AM
> *To:* Shah, Himanshu <[email-masked]>; Jeff Tantsura <
> [email-masked]>; Bernier, Daniel <[email-masked]>;
> [email-masked]; [email-masked]
> *Cc:* Alvaro Retana (aretana) <[email-masked]>; [email-masked]
>
> *Subject:* Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering
> discussion
>
> [DV] see inlines
>
> *From: *spring <[email-masked]> on behalf of "Shah, Himanshu" <
> [email-masked]>
> *Date: *Sunday, March 18, 2018 at 9:23 PM
> *To: *Jeff Tantsura <[email-masked]>, Daniel Bernier <
> [email-masked]>, Bruno Decraene <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Cc: *"Alvaro Retana (aretana)" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering
> discussion
>
> Agree with Jeff, without harping on all the good reasons already stated
> for SPRING WG charter extensions,
> I would think that it would be beneficial to leverage TE expertise from
> TEAS WG to
> progress SR-TE there for a cohesive, uniform solution for all tunneling
> schemes.
>
> [DV] 1- SRTE is NOT a tunnel. Labels are signals straight in the IGP, as
> known. This is why the word “policy” was introduce with SRTE – “SRTE
> Policy”.
> [DV] 2- According to TEAS WG charter - https://datatracker.ietf.
> org/wg/teas/about/:
> 1. Definition of additional abstract service, link, and path
> properties such as jitter, delay, and diversity. Extensions
> to IGPs to advertise these properties, and
> *extensions to  RSVP-TE *to request and to accumulate these properties.
>
> [DV] 3- also notice in the SPRING Charter - https://datatracker.ietf.
> org/wg/spring/about/:
> o Some types of network virtualization, including multi-
> topology networks and the partitioning of network
> resources for VPNs
> o Network path and node protection such as fast re-route
> o Network programmability
> o New OAM techniques
> o Simplification and reduction of network signalling
> components
> o Load balancing and *traffic engineering*
> [DV] Hence I believe “SRTE policy” is a key component of the SR
> Architecture and should pursued as part as the Architecture definition
> milestone of the SPRING WG.
>
> Dan
>
> IMHO..
>
> *Thanks,*
> *Himanshu*
> *From: *spring <[email-masked]> on behalf of Jeff Tantsura <
> [email-masked]>
> *Date: *Sunday, March 18, 2018 at 3:26 PM
> *To: *"Bernier, Daniel" <[email-masked]>, "
> [email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]>
> *Cc: *Alvaro Retana <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *[**EXTERNAL**] Re: [spring] SPRING - rechartering discussion
>
> 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&M 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" <
> [email-masked] on behalf of [email-masked]> 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 <[email-masked]> on behalf of
> [email-masked] <[email-masked]>
>     Sent: Monday, March 5, 2018 11:59 AM
>     To: [email-masked]
>     Cc: Alvaro Retana (aretana); [email-masked]
>     Subject: [spring] SPRING - rechartering discussion
>
>     Hello WG,
>
>     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]
> <[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
>     _______________________________________________
>     spring mailing list
>     [email-masked]
>     https://www.ietf.org/mailman/listinfo/spring
>
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>
>

---

From: "Kamran Raza (skraza)" <[email-masked]>
Date: Wed, 21 Mar 2018 01:45:28 +0000

+1

I also believe that SR-policy falls under the charter of SPRING WG and not TEAS.
Thx
--
Kamran

From: spring <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Tuesday, March 20, 2018 at 11:59 PM
To: "Darren Dukes (ddukes)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

All,

I am not even sure why do we need to discuss applicability of SR-TE to TEAS WG ... Who started that idea ?

TEAS WG charter states:

SR TE or for that matter BGP TE (by adjusting BGP policies via BGP attributes) or OSPF/ISIS TE (by adjusting IGP metrics) have nothing to do with MPLS or GMPLS. So it should be pretty obvious for those even not very much skilled with that art that this entire discussion is a classic red herring and it should be stopped and archived ASAP.

Kind regards,
Robert.

On Wed, Mar 21, 2018 at 12:45 AM, Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>> wrote:
+1 for Paul, Martin, Dan on SR TE.  I tried to type up something beyond what you’ve said, but deleted it…

As an coder of SR TE Policy, I can confirm that it is as far away from RSVP-TE as possible.

Darren

On Mar 20, 2018, at 2:45 PM, Paul Mattes <[email-masked]<mailto:[email-masked]>> wrote:

I do not know a great deal about the inner workings of the TEAS WG. I have no doubt that the TE activities inside the SPRING WG could benefit from close collaboration with TEAS. On the other hand, SR-TE has evolved as a quite different approach from the distributed RSVP-TE architecture -- something that makes it very attractive as a replacement for RSVP-TE in our application.

Could the TEAS charter be generalized to include this approach (as it would apparently need to be)? Sure. Would separating SR-TE from a WG completing a coherent SR architecture help or hinder it? It would hinder it, I fear, because it might go from being one of the things that really fulfills the promise of SR to being an uncomfortable step-child of a broader traffic engineering effort.

(I would love to hear the opposite argument – that many in the TEAS WG would like to build on SR-TE policy and its approach as a way to move TE forward. Might that be true?)

        pdm

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Voyer, Daniel
Sent: Monday, March 19, 2018 6:42 AM
To: Shah, Himanshu <[email-masked]<mailto:[email-masked]>>; Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; Bernier, Daniel <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

[DV] see inlines

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of "Shah, Himanshu" <[email-masked]<mailto:[email-masked]>>
Date: Sunday, March 18, 2018 at 9:23 PM
To: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, Daniel Bernier <[email-masked]<mailto:[email-masked]>>, Bruno Decraene <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

Agree with Jeff, without harping on all the good reasons already stated for SPRING WG charter extensions,
I would think that it would be beneficial to leverage TE expertise from TEAS WG to
progress SR-TE there for a cohesive, uniform solution for all tunneling schemes.

[DV] 1- SRTE is NOT a tunnel. Labels are signals straight in the IGP, as known. This is why the word “policy” was introduce with SRTE – “SRTE Policy”.
[DV] 2- According to TEAS WG charter - https://datatracker.ietf.org/wg/teas/about/:
1. Definition of additional abstract service, link, and path
properties such as jitter, delay, and diversity. Extensions
to IGPs to advertise these properties, and extensions to
RSVP-TE to request and to accumulate these properties.

[DV] 3- also notice in the SPRING Charter - https://datatracker.ietf.org/wg/spring/about/:
o Some types of network virtualization, including multi-
topology networks and the partitioning of network
resources for VPNs
o Network path and node protection such as fast re-route
o Network programmability
o New OAM techniques
o Simplification and reduction of network signalling
components
o Load balancing and traffic engineering
[DV] Hence I believe “SRTE policy” is a key component of the SR Architecture and should pursued as part as the Architecture definition milestone of the SPRING WG.

Dan

IMHO..

Thanks,
Himanshu
From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Date: Sunday, March 18, 2018 at 3:26 PM
To: "Bernier, Daniel" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [**EXTERNAL**] Re: [spring] SPRING - rechartering discussion

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&M 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" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> 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) ?

    Daniel Bernier | Bell Canada
    ________________________________________
    From: spring <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:bruno.decraene@orange..com>>
    Sent: Monday, March 5, 2018 11:59 AM
    To: [email-masked]<mailto:[email-masked]>
    Cc: Alvaro Retana (aretana); [email-masked]<mailto:[email-masked]>
    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.

    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.

     * 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'll likely have a dedicated slot in London but we'd like to progress before that.

    Thank you,
    --Martin, Rob, Bruno

     > From: Martin Vigoureux [mailto:[email-masked]]
     > To: [email-masked]<mailto:[email-masked]>
     > Cc: [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana)
     > in the session we have opened the discussion on the future of the WG,
     > 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),
     > desired and one reason for that is to have a home to share and discuss
     > There are also a few individual documents knocking at the door, and some
     > To reach out to everyone, we are thus asking the question on the list.
     > Note, the expectation is that future items should not be use-cases but

    _________________________________________________________________________________________________________________________

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

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

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

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

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 21 Mar 2018 05:27:37 +0000

I agree also with that. SR-TE is a different technology compared to TEAS/RSVP/GMPLS. So I agree to keep this work in SPRING WG and progress it there.

From: spring <[email-masked]> on behalf of "Kamran Raza (skraza)" <[email-masked]>
Date: Wednesday, 21 March 2018 at 01:45
To: Robert Raszuk <[email-masked]>, "Darren Dukes (ddukes)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

+1

All,

TEAS WG charter states:

Kind regards,
Robert.

Darren

        pdm

[DV] see inlines

Dan

IMHO..

Thanks,
Himanshu

Hi,

Cheers,
Jeff

    Hi,

    Hello WG,

     * service chaining

     * yang

    Thank you,
    --Martin, Rob, Bruno

---

From: Gaurav Dawra <[email-masked]>
Date: Wed, 21 Mar 2018 13:58:58 +0000

+1. SR-Policy is part of SPRING Charter.

Sent from my iPhone

> On Mar 21, 2018, at 1:45 AM, Kamran Raza (skraza) <[email-masked]> wrote:
> 
> +1
>  
> On Wed, Mar 21, 2018 at 12:45 AM, Darren Dukes (ddukes) <[email-masked]> wrote:
> From: spring <[email-masked]> On Behalf Of Voyer, Daniel
> To: Shah, Himanshu <[email-masked]>; Jeff Tantsura <[email-masked]>; Bernier, Daniel <[email-masked]>; [email-masked]; [email-masked]
> Cc: Alvaro Retana (aretana) <[email-masked]>; [email-masked]
> 
> From: spring <[email-masked]> on behalf of "Shah, Himanshu" <[email-masked]>
> To: Jeff Tantsura <[email-masked]>, Daniel Bernier <[email-masked]>, Bruno Decraene <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc: "Alvaro Retana (aretana)" <[email-masked]>, "[email-masked]" <[email-masked]>
> From: spring <[email-masked]> on behalf of Jeff Tantsura <[email-masked]>
> To: "Bernier, Daniel" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc: Alvaro Retana <[email-masked]>, "[email-masked]" <[email-masked]>
> On 3/18/18, 13:23, "spring on behalf of Bernier, Daniel" <[email-masked] on behalf of [email-masked]> wrote:
>  
>     Hi,
>     
>     From: spring <[email-masked]> on behalf of [email-masked] <[email-masked]>

---

From: "Leddy, John" <[email-masked]>
Date: Wed, 21 Mar 2018 14:22:54 +0000

One the major advantages I see of SR is the ability to have SR-Policy that can express Network Paths in a chain of NFV components.  The decision isn’t just the Network path, it includes which instance of an NFV component (including the option of spinning up a new NFV instance in a specific locations).

I am concerned that if these are broken into 2 distinct efforts many benefits will be missed.

From: Gaurav Dawra <[email-masked]>
Date: Wednesday, March 21, 2018 at 1:58 PM
To: "Kamran Raza (skraza)" <[email-masked]>
Cc: Robert Raszuk <[email-masked]>, "Darren Dukes (ddukes)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

On Mar 21, 2018, at 1:45 AM, Kamran Raza (skraza) <[email-masked]<mailto:[email-masked]>> wrote:
+1

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 20, 2018 at 11:59 PM
To: "Darren Dukes (ddukes)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

All,

TEAS WG charter states:

Kind regards,
Robert.

Darren

        pdm

[DV] see inlines

Dan

IMHO..

Thanks,
Himanshu

Hi,

Cheers,
Jeff

    Hi,

    Hello WG,

     * service chaining

     * yang

    Thank you,
    --Martin, Rob, Bruno

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