+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 protected]> 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:
>
>
>
> o Some types of network virtualization, including multi-
> topology networks and the partitioning of network
> resources for VPNs
>
>
>
> 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 protected]] *On Behalf Of *Voyer,
> Daniel
> *Sent:* Monday, March 19, 2018 11:42 AM
> *To:* Shah, Himanshu; Jeff Tantsura; Bernier, Daniel;
> [email protected]; [email protected]
>
>
> *Cc:* Alvaro Retana (aretana); [email protected]
>
> *Subject:* Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering
> discussion
>
>
>
> [DV] see inlines
>
>
>
> *From: *spring <[email protected]> on behalf of "Shah, Himanshu" <
> [email protected]>
> *Date: *Sunday, March 18, 2018 at 9:23 PM
> *To: *Jeff Tantsura <[email protected]>, Daniel Bernier <
> [email protected]>, Bruno Decraene <[email protected]>, "
> [email protected]" <[email protected]>
> *Cc: *"Alvaro Retana (aretana)" <[email protected]>, "
> [email protected]" <[email protected]>
> *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 protected]> on behalf of Jeff Tantsura <
> [email protected]>
> *Date: *Sunday, March 18, 2018 at 3:26 PM
> *To: *"Bernier, Daniel" <[email protected]>, "
> [email protected]" <[email protected]>, "[email protected]"
> <[email protected]>
> *Cc: *Alvaro Retana <[email protected]>, "[email protected]" <
> [email protected]>
> *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 protected] on behalf of [email protected]> 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 protected]> on behalf of
> [email protected] <[email protected]>
>
>     Sent: Monday, March 5, 2018 11:59 AM
>
>     To: [email protected]
>
>     Cc: Alvaro Retana (aretana); [email protected]
>
>     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 protected]
> <[email protected]>]
>
>      > Sent: Wednesday, March 29, 2017 4:25 PM
>
>      > To: [email protected]
>
>      > Cc: [email protected]; 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 protected]
>
>     https://www.ietf.org/mailman/listinfo/spring
>
>     _______________________________________________
>
>     spring mailing list
>
>     [email protected]
>
>     https://www.ietf.org/mailman/listinfo/spring
>
>
>
>
>
>
>
> _______________________________________________
>
> spring mailing list
>
> [email protected]
>
> https://www.ietf.org/mailman/listinfo/spring
>
>
> _______________________________________________
> spring mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

-- Alex

Alex Bogdanov | Strategic NetEng | bogdanov@ <[email protected]> | Cell:
650-314-8196
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring

Reply via email to