[ieee-ietf-coord] FW: [new-work] WG Review: Traffic Engineering Architecture and Signaling (teas)

["Romascanu, Dan (Dan)" <[e-mail]>]

Please forward to the relevant WGs in IEEE 802. 

Thanks and Regards,

Dan



> -----Original Message-----
> From: new-work [mailto:[e-mail]] On Behalf Of The
> IESG
> Sent: Tuesday, November 25, 2014 11:13 PM
> To: [e-mail]
> Subject: [new-work] WG Review: Traffic Engineering Architecture and
> Signaling (teas)
> 
> A new IETF working group has been proposed in the Routing Area. The IESG
> has not made any determination yet. The following draft charter was
> submitted, and is provided for informational purposes only. Please send your
> comments to the IESG mailing list (iesg at ietf.org) by 2014-12-02.
> 
> Traffic Engineering Architecture and Signaling (teas)
> ------------------------------------------------
> Current Status: Proposed WG
> 
> Chairs:
>   Deborah Brungard <[e-mail]>
>   Lou Berger <[e-mail]>
> 
> Assigned Area Director:
>   Adrian Farrel <[e-mail]>
> 
> Mailing list
>   Address: [e-mail]
>   To Subscribe: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_teas&d=AAICAg&c=BFpWQw8bsuKpl1
> SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=8zSoCW
> NzuqGD2hHUFOKAUy0JOej94Zj4TlDWdmjGpNA&s=-
> 1Pal0_I2Q2UMbdSGM3bqMFHVg5J3dP5XB9AC9ekR-M&e=
>   Archive: https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.ietf.org_mail-
> 2Darchive_web_teas_&d=AAICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGx
> R31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=8zSoCWNzuqGD2hHUFOKA
> Uy0JOej94Zj4TlDWdmjGpNA&s=Q6YCRJkJJWtV_I6JwV2qPfejOXk8URJP3K8r
> bFNBQc8&e=
> 
> Charter:
> 
> The Traffic Engineering Architecture and Signaling (TEAS) Working Group is
> responsible for defining MPLS and GMPLS traffic engineering architecture,
> standardizing the RSVP-TE signaling protocol, and identifying required related
> control-protocol functions, i.e., routing and path computation element
> functions.
> 
> Traffic Engineering (TE) is the term used to refer to techniques that enable
> operators to control how specific traffic flows are treated within their
> networks. TE is applied to packet networks via MPLS TE tunnels and LSPs. The
> MPLS-TE control plane was generalized to additionally support non-packet
> technologies via GMPLS.  RSVP-TE is the signaling protocol used for both
> MPLS-TE and GMPLS.
> 
> The TEAS WG is responsible for:
> 
>  a) Traffic-engineering architectures for generic applicability
>     across packet and non-packet networks. This includes both
>     networks that include the use of PCE and those that do not.
>     The PCE architecture itself is out of the WG scope.
> 
>  b) Definition of protocol-independent metrics and parameters
>     (measurement and/or service attributes) for describing
>     links and tunnels/paths required for traffic engineering
>     (and related routing, signaling and path computation).
>     These will be developed in conjunction with requests and
>     requirements from other WGs to ensure overall usefulness.
> 
>  c) Functional specification of extensions for routing (OSPF,
>     ISIS) and for path computation (PCE) to provide general
>     enablers of traffic-engineering systems that also use
>     RSVP-TE. Protocol formats and procedures that embody these
>     extensions will be done in coordination with the WGs
>     supervising those protocols.
> 
>  d) Functional specification of generic (i.e., not data plane
>     technology-specific) extensions for RSVP-TE, and the
>     associated protocol formats and procedures that embody
>     these extensions.
> 
>  e) Definition of control plane mechanisms and extensions to allow
>     the setup and maintenance of TE paths and TE tunnels that span
>     multiple domains and/or switching technologies, where a
>     domain may be an IGP area, an Autonomous System, or any other
>     region of topological visibility.
> 
>  f) Definition and extension of management and security techniques
>     for RSVP-TE signaling. This includes configuring and monitoring
>     RSVP-TE as well as mechanisms used to configure, control, and
>     report OAM within TE networks. YANG and MIB modules may be
>     considered.
> 
> The TEAS working group is chartered to deliver the following:
> 
>  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. Work
>     with PCE WG to include these properties in computation
>     requests.
> 
>  2. Specification of terminology, architecture, and protocol
>     requirements for abstraction and distribution of TE
>     information between interconnected TE domains/layers.
> 
>  3. Specification and protocol extensions for a GMPLS External
>     Network-to-Network Interface (E-NNI), i.e., multi-domain
>     GMPLS support.
> 
>  4. Protocol mechanisms to signal associated LSPs in particular
>     with different source nodes.
> 
>  5. Requirements and protocol extensions for additional protection
>     mechanisms including end-point protection, protection of P2MP
>     LSPs, and inter-domain protection.
> 
>  6. YANG models for a Traffic Engineering Database in coordination
>     with working groups working on YANG models for network
>     topology and for technology-specific network attributes.
> 
> Requirements may be documented in stand-alone RFCs, may be folded into
> architecture or solutions RFCs, may be recorded on a wiki, or may be
> documented in an Internet-Draft that is not progressed to RFC.
> 
> The TEAS WG will coordinate with the following working groups:
> 
>  - With the MPLS WG to maintain and extend MPLS-TE protocol
>    mechanisms and to determine whether they should be generalized.
> 
>  - With the CCAMP WG to maintain and extend non-packet, data plane
>    technology-specific TE protocol mechanisms and to determine
>    whether they should be generalized.
> 
>  - With the OSPF and ISIS WGs to maintain or extend TE routing
>    mechanisms for MPLS-TE and GMPLS.
> 
>  - With the PCE WG on uses of a PCE in the traffic-engineering
>    architecture, on PCE extensions per the above, and on RSVP-TE
>    extensions to support PCE WG identified requirements.
> 
>  - With the IDR WG on the use of BGP-LS in TE environments.
> 
> In doing this work, the WG will cooperate with external SDOs (such as the
> ITU-T and the IEEE 802.1) as necessary.
> 
> Milestones:
> 
> TBD
> 
> _______________________________________________
> new-work mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_new-
> 2Dwork&d=AAICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQz
> vlsiLQfucBXRucPvdrphpBsFA&m=8zSoCWNzuqGD2hHUFOKAUy0JOej94Zj4Tl
> DWdmjGpNA&s=Bs99k31SHNZBvOZRKxqH1ns736ryJYnkIjI-U_2s_MA&e=