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

From: "Shah, Himanshu" <[email-masked]>
Date: Sun, 18 Mar 2018 21:22:44 +0000

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.

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]<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) ?

    My humble operator 0.02 cents.

    Daniel Bernier | Bell Canada
    ________________________________________
    From: spring <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
    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.

    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]<mailto:[email-masked]>
     > Cc: [email-masked]<mailto:[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]<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: "Voyer, Daniel" <[email-masked]>
Date: Mon, 19 Mar 2018 11:42:14 +0000

[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

[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

Hi,

Cheers,
Jeff

    Hi,

    Hello WG,

     * service chaining

     * yang

    Thank you,
    --Martin, Rob, Bruno

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 19 Mar 2018 14:23:37 +0000

Hi all,

I totally agree with Mach, Jeff and others that there is work to be done in OAM as there are more requirements to use SR for both existing and emerging applications.

SR-TE is another important area. The current SR-TE mainly focuses on steering traffic to particular SR paths, while TE can have a broader scope than that, for example, how to do resource partitioning (reservation) with SR needs to be discussed.  Actually this is already mentioned in the current charter:

I’d agree with Dan that SR-TE is different from RSVP-TE, while as Himanshu said, it could be beneficial to leverage the TE expertise from TEAS.

Best regards,
Jie

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

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,

Cheers,
Jeff

    Hi,

    Hello WG,

     * service chaining

     * yang

    Thank you,
    --Martin, Rob, Bruno

---

From: Alex Bogdanov <[email-masked]>
Date: Mon, 19 Mar 2018 18:37:11 +0000

+1 to traffic steering  and OAM. I'd like to see operational
statistics/traffic accounting get some much deserved attention(in the
context of SRTE policies and other SR paths)

On Mon, Mar 19, 2018 at 7:23 AM Dongjie (Jimmy) <[email-masked]> wrote:

> Hi all,
>
>
>
> I totally agree with Mach, Jeff and others that there is work to be done
> in OAM as there are more requirements to use SR for both existing and
> emerging applications.
>
>
>
> SR-TE is another important area. The current SR-TE mainly focuses on
> steering traffic to particular SR paths, while TE can have a broader scope
> than that, for example, how to do resource partitioning (reservation) with
> SR needs to be discussed.  Actually this is already mentioned in the
> current charter:
>
>
>
> I’d agree with Dan that SR-TE is different from RSVP-TE, while as Himanshu
> said, it could be beneficial to leverage the TE expertise from TEAS.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* spring [mailto:[email-masked]] *On Behalf Of *Voyer,
> Daniel
> *Sent:* Monday, March 19, 2018 11:42 AM
> *To:* Shah, Himanshu; Jeff Tantsura; Bernier, Daniel;
> [email-masked]; [email-masked]
>
>
> *Cc:* Alvaro Retana (aretana); [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
>
>
>
> [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/:
>
> 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 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,
>
>
>
> 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) ?
>
>
>
>     From: spring <[email-masked]> on behalf of
> [email-masked] <[email-masked]>
>
>     To: [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).
>
>      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
>
>      > From: Martin Vigoureux [mailto:[email-masked]
> <[email-masked]>]
>
>      > To: [email-masked]
>      > Cc: [email-masked]; Alvaro Retana (aretana)
>
>     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,
>
>     This message and its attachments may contain confidential or
> privileged information that may be protected by law;
>
>     [email-masked]
>     [email-masked]
> [email-masked]
> [email-masked]
-- 

-- Alex

Alex Bogdanov | Strategic NetEng | bogdanov@ <[email-masked]> | Cell:
650-314-8196

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Tue, 20 Mar 2018 01:10:08 +0000

Hi All,

I could not agree more with Dan.

As indicated by the text quoted by Dan from the Spring charter [https://datatracker.ietf.org/wg/spring/about/], SR Policy specification is not only part of the current Spring Charter; it is the basis of "source routing" and is the heart of the Spring WG. The SR architecture is incomplete without SR Policy specification in it. The work on SR Policies is part of the SR architecture deliverables and belongs to the Spring WG.

TEAS WG should review the work and provide comments. However, as shown by the text quoted by Dan [ https://datatracker.ietf.org/wg/teas/about/] SR policy specification is beyond the scope of TEAS WG.

Thanks

Regards … Zafar

From: spring <[email-masked]> on behalf of "Voyer, Daniel" <[email-masked]>
Date: Monday, March 19, 2018 at 11:42 AM
To: "Shah, Himanshu" <[email-masked]>, Jeff Tantsura <[email-masked]>, "Bernier, Daniel" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "Alvaro Retana (aretana)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

[DV] see inlines

Dan

IMHO..

Thanks,
Himanshu

Hi,

Cheers,
Jeff

    Hi,

    Hello WG,

     * service chaining

     * yang

    Thank you,
    --Martin, Rob, Bruno

---

From: "Chengli (IP Technology Research)" <[email-masked]>
Date: Tue, 20 Mar 2018 02:10:44 +0000

Hi all,

Yes,+1 to traffic steering and OAM.  As mentioned by Mach, Zafar and others,  OAM is very important for SR to be deployed in a production network, and there are many works of OAM have been done. They should be added to Charter so that SR can be developed well since the fundamental SR mechanism is almost done for now.

I think operators will be happy to see SR can be deployed with rich OAM features in their  production networks.

Best regards
Cheng

From: spring [mailto:[email-masked]] On Behalf Of Alex Bogdanov
Sent: Tuesday, March 20, 2018 2:37 AM
To: Dongjie (Jimmy) <[email-masked]>
Cc: [email-masked]; [email-masked]; Shah, Himanshu <[email-masked]>; [email-masked]; Bernier, Daniel <[email-masked]>; Alvaro Retana (aretana) <[email-masked]>; Jeff Tantsura <[email-masked]>; Voyer, Daniel <[email-masked]>
Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

+1 to traffic steering  and OAM. I'd like to see operational statistics/traffic accounting get some much deserved attention(in the context of SRTE policies and other SR paths)

On Mon, Mar 19, 2018 at 7:23 AM Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Best regards,
Jie

From: spring [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Voyer, Daniel
Sent: Monday, March 19, 2018 11:42 AM
To: Shah, Himanshu; Jeff Tantsura; Bernier, Daniel; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

[DV] see inlines

Dan

IMHO...

Thanks,
Himanshu

Hi,

Cheers,
Jeff

    Hi,

    Hello WG,

    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.

     * service chaining

     * yang

    Thank you,
    --Martin, Rob, Bruno

-- Alex

Alex Bogdanov | Strategic NetEng | bogdanov@<mailto:[email-masked]> | Cell: 650-314-8196

---

From: Martin Horneffer <[email-masked]>
Date: Tue, 20 Mar 2018 14:27:10 +0000

+1

Or, to be more explicit, mentioning TEAS is - in my eyes - a major 
reason to insist in keeping the SPRING wg for a while, and for
having the SRE-TE discussions here and not there!!!

While it's always good to learn from each other, I strongly believe that 
moving any SR-TE discussion to TEAS would do nobody any good. As Dan 
pointed out, TEAS is about RSVP-TE. And it has a completely different 
way of approaching TE than what we want to do with SR. I really believe 
it's better to keep the different approaches to TE separate, rather than 
to coerce opposite minds to do their work in a joint forum, which most 
likely just leads to religious wars rather than anything productive.

 From my point of view, the TEAS charter even defines "traffic 
engineering" in a way which is completely ignorant and insulting. I 
don't feel like interfering with that, as long as everyone can still get 
their job done. But this tolerance wouldn't work any more if the SR-TE 
discussions would have to move there.

Best regards, Martin

P.S.: It's not like I was blindly ignorant towards RSVP-TE. In more than 
15 years of experience with traffic engineering, I have used and 
accounted for RSVP more than once, in more than one or two independet 
IP/MPLS networks. Just recently I did recommend to use RSVP for specific 
use cases in a specific network. But I have the strong opinion that it's 
not the only solution for traffic engineering problems, and depending on 
the exact frame conditions it might not at all be the best overall solution.

Am 19.03.18 um 11:42 schrieb Voyer, Daniel:
>
> [DV] see inlines
>
> *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]>
> [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”.
>
> https://datatracker.ietf.org/wg/teas/about/ 
> <https://datatracker.ietf.org/wg/teas/about/>:
>
> to IGPs to advertise these properties, and _extensions to
> RSVP-TE _to request and to accumulate these properties.
>
> o Load balancing and _traffic engineering_
>
> /Thanks,/
> /Himanshu/
> *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]>
> 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.
>
> 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) ?
>
>     From: spring <[email-masked] 
> <mailto:[email-masked]>> on behalf of 
> [email-masked] <mailto:[email-masked]> 
> <[email-masked] <mailto:[email-masked]>>
>
>     To: [email-masked] <mailto:[email-masked]>
>
> <mailto:[email-masked]>
>
> 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.
>
>      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
>
>      > -----Original Message-----
>
>      > From: Martin Vigoureux [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,
>
>      >
>
>      > 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
>
>     pas etre diffuses, exploites ou copies sans autorisation. Si vous 
> avez recu ce message par erreur, veuillez le signaler
>
>     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.
>
> [email-masked] <mailto:[email-masked]>
>
> [email-masked] <mailto:[email-masked]>
>
> [email-masked] <mailto:[email-masked]>
>

---

From: Paul Mattes <[email-masked]>
Date: Tue, 20 Mar 2018 18:45:01 +0000

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

Dan

IMHO..

Thanks,
Himanshu

Hi,

Cheers,
Jeff

    Hi,

    Hello WG,

     * service chaining

     * yang

    Thank you,
    --Martin, Rob, Bruno

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 20 Mar 2018 23:45:56 +0000

+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]<mailto:[email-masked]>> wrote:

        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

Dan

IMHO..

Thanks,
Himanshu

Hi,

Cheers,
Jeff

    Hi,

    Hello WG,

     * service chaining

     * yang

    Thank you,
    --Martin, Rob, Bruno

---

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:

> 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]>;
> *Cc:* Alvaro Retana (aretana) <[email-masked]>; [email-masked]
>
>     ________________________________________________________
> _________________________________________________________________
>

---

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…

Darren

        pdm

[DV] see inlines

Dan

IMHO..

Thanks,
Himanshu
From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Jeff Tantsura <[email-masked]<mailto:[email-masked]>>

Hi,

Cheers,
Jeff

    Hi,

    From: spring <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:bruno.decraene@orange..com>>

    Hello WG,

     * service chaining

     * yang

    Thank you,
    --Martin, Rob, Bruno

---

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: Martin Horneffer <[email-masked]>
Date: Wed, 21 Mar 2018 06:20:58 +0000

Having been told that my sentence about the TEAS charter was perceived 
as agressive I want to apologize for my exaggeration.

That sentence should have better been something like:

    Reading the TEAS charter I felt personally insulted as it generally
    defines the term "traffic engineering", but in a way that doesn't
    allow for any other methodology but using RSVP.

Apparently that feeling of insult made me choose aggressive words, which 
I shouldn't have used. It was not my intention to hurt anyone in return.

Best regards, Martin

Am 20.03.18 um 14:27 schrieb Martin Horneffer:
> While it's always good to learn from each other, I strongly believe 
> that moving any SR-TE discussion to TEAS would do nobody any good. As 
> Dan pointed out, TEAS is about RSVP-TE. And it has a completely 
> different way of approaching TE than what we want to do with SR. I 
> really believe it's better to keep the different approaches to TE 
> separate, rather than to coerce opposite minds to do their work in a 
> joint forum, which most likely just leads to religious wars rather 
> than anything productive.
>
> don't feel like interfering with that, as long as everyone can still 
> get their job done. But this tolerance wouldn't work any more if the 
> SR-TE discussions would have to move there.
>
> Best regards, Martin
>
> P.S.: It's not like I was blindly ignorant towards RSVP-TE. In more 
> than 15 years of experience with traffic engineering, I have used and 
> IP/MPLS networks. Just recently I did recommend to use RSVP for 
> specific use cases in a specific network. But I have the strong 
> opinion that it's not the only solution for traffic engineering 
> problems, and depending on the exact frame conditions it might not at 
> all be the best overall solution.
>
>
>> *From: *spring <[email-masked]> on behalf of "Shah, 
>> Himanshu" <[email-masked]>
>> Architecture and should pursued as part as the Architecture 
>> definition milestone of the SPRING WG.
>>
>> Dan
>>
>> IMHO..
>>
>> /Thanks,/
>>
>> /Himanshu/
>>
>> <[email-masked] <mailto:[email-masked]> on behalf 
>> of [email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Hi,
>>
>> 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) ?
>>
>>     now that nearly all the core documents are in the hands of IESG 
>> or beyond, we think it is time to (re)discuss rechartering.
>>
>> that  time, was that the WG at least needs to be maintained to 
>> discuss the extensions following deployment feedback.
>>
>>      > There are also a few individual documents knocking at the 
>> door, and some
>>
>>     Ce message et ses pieces jointes peuvent contenir des 
>> informations confidentielles ou privilegiees et ne doivent donc
>>
>>     If you have received this email in error, please notify the 
>> sender and delete this message and its attachments.
>>

---

From: <[email-masked]>
Date: Wed, 21 Mar 2018 11:19:12 +0000

Martin,

Thanks. I’d be glad if the discussion returns to charter contents and usual WG cooperation.

Work of TEAS should progress independently from Spring. My take of the TEAS WG is, that Traffic Engineering linked to RSVP TE is covered there. Spring policy routing isn’t linked to RSVP-TE signaling and I’m not aware of any requirement to add RSVP-TE signaling to Spring policy routing. To me, the following would make sense:

  *   All aspects of Spring policy routing which are not linked to RSVP-TE signaling are pursued by an appropriately re-chartered Spring WG.
  *   If terminology is an issue, SR “Traffic Engineering” to me can be replaced by “SR Policy Routing” or another suitable term. I’m interested in fast progress of the SR policy routing within Spring WG and I don’t want this progress to be blocked by words.
  *   There’s a draft listed by Spring, but not by TEAS: https://www.ietf.org/id/draft-ietf-teas-sr-rsvp-coexistence-rec-02.txt . I think it describes how both approaches can coexist.
  *   If there’s interest by the TEAS WG to work on solutions combining Spring and RSVP-TE signaling, then the TEAS Charter needs to be adapted. Spring or Segment Routing are not mentioned by it.

I hope that Spring WG succeeds in re-chartering to cover all aspects of SR policy routing (excluding RSVP-TE signaling) and related OAM and TEAS can make progress on their chartered work items. I’d appreciate the usual IETF style cooperation of both WGs, if there’s an overlap on contents.

Regards,

Ruediger

Von: spring [mailto:[email-masked]] Im Auftrag von Martin Horneffer
Gesendet: Mittwoch, 21. März 2018 07:21
An: [email-masked]
Cc: [email-masked]
Betreff: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

Having been told that my sentence about the TEAS charter was perceived as agressive I want to apologize for my exaggeration.

That sentence should have better been something like:
Reading the TEAS charter I felt personally insulted as it generally defines the term "traffic engineering", but in a way that doesn't allow for any other methodology but using RSVP.

Apparently that feeling of insult made me choose aggressive words, which I shouldn't have used. It was not my intention to hurt anyone in return.

Best regards, Martin

Or, to be more explicit, mentioning TEAS is - in my eyes - a major reason to insist in keeping the SPRING wg for a while, and for
having the SRE-TE discussions here and not there!!!

While it's always good to learn from each other, I strongly believe that moving any SR-TE discussion to TEAS would do nobody any good. As Dan pointed out, TEAS is about RSVP-TE. And it has a completely different way of approaching TE than what we want to do with SR. I really believe it's better to keep the different approaches to TE separate, rather than to coerce opposite minds to do their work in a joint forum, which most likely just leads to religious wars rather than anything productive.

From my point of view, the TEAS charter even defines "traffic engineering" in a way which is completely ignorant and insulting. I don't feel like interfering with that, as long as everyone can still get their job done. But this tolerance wouldn't work any more if the SR-TE discussions would have to move there.

Best regards, Martin

P.S.: It's not like I was blindly ignorant towards RSVP-TE. In more than 15 years of experience with traffic engineering, I have used and accounted for RSVP more than once, in more than one or two independet IP/MPLS networks. Just recently I did recommend to use RSVP for specific use cases in a specific network. But I have the strong opinion that it's not the only solution for traffic engineering problems, and depending on the exact frame conditions it might not at all be the best overall solution.

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

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,

Cheers,
Jeff

    Hi,

    Hello WG,

     * service chaining

     * yang

    Thank you,
    --Martin, Rob, Bruno

spring mailing list

spring mailing list

---

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 Jeff Tantsura <[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>

---

From: stefano previdi <[email-masked]>
Date: Thu, 22 Mar 2018 09:50:33 +0100

SPRINGers,

> On Mar 19, 2018, at 3:23 PM, Dongjie (Jimmy) <[email-masked]> wrote:
> 
> Hi all,
>  
> SR-TE is another important area. The current SR-TE mainly focuses on steering traffic to particular SR paths, while TE can have a broader scope than that, for example, how to do resource partitioning (reservation) with SR needs to be discussed.  

I agree with the above. This is yet another aspect of TE that needs to be addressed.

Also, the v6 side of SR will also require more work, e.g., in the definition of use cases that clearly benefit from extension header insertion so that (minor) changes can be proposed to the v6 specification allowing these use cases to be implemented and operated safely.

s.

> Actually this is already mentioned in the current charter:
>

---

From: Lizhenbin <[email-masked]>
Date: Thu, 22 Mar 2018 10:15:59 +0000

The SR-TE policy work has been done for a long time in SRPING WG. In addition though the name is a little misleading, I would like to remind you of the work of the draft-ietf-idr-segment-routing-te-policy-02 which has much relation with the draft-filsfils-spring-segment-routing-policy-05 in SPRING WG from which we can see the work of SR-TE policy is much beyond the scope of TEAS WG. Based on the observation I think the work should be incorporated in the recharter of SPRING WG.

________________________________________
发件人: spring [[email-masked]] 代表 stefano previdi [[email-masked]]
发送时间: 2018年3月22日 16:50
收件人: Dongjie (Jimmy)
抄送: [email-masked]; [email-masked]; Shah, Himanshu; Alvaro Retana; Bruno Decraene; Bernier, Daniel; Jeff Tantsura; Voyer, Daniel
主题: Re: [spring] [**EXTERNAL**] Re:  SPRING - rechartering discussion

SPRINGers,

s.

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Fri, 23 Mar 2018 11:07:11 +0000

I think useful to breakdown some aspects about SR policies:
- related to candidate paths instantiation/reporting/update –via PCEP, BGP, et. al – and related extensions.. IMO, there’s some work to be done there
- related path computation/formulation/validation – it’s clear SR paths are not 1:1 with RSVP hops, and SIDs are not necessarily always forwarding instructions— It is likely however a single stateful controller will have to deal with both SR policies and RSVP-TE LSPs on a single TED network to do meaningful path computation/placement. In here, I think staying in sync with TEAS would be beneficial.
- specific to srv6 dataplane and nsh
- specific to color based service steering

There's enough to distinguish SR policies from RSVP LSPs and it'd be good to treat/model them differently to reduce confusion and complexity.

Regards,
Tarek

On 2018-03-22, 10:33 AM, "spring on behalf of Lizhenbin" <[email-masked] on behalf of [email-masked]> wrote:

    
    SPRINGers,

    
    
    s.