Re: [Teas] Proposed charter update

[Dhruv Dhody <[e-mail]>]

Hi Lou,

OLDER: 
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.

OLD:
a) Traffic-engineering architectures for generic applicability
across packet and non-packet networks.. This includes, for example,
both networks that include the use of PCE and those that conform with
ACTN principles but don't make use of PCE. The PCE architecture itself
is out of the WG scope.

NEW: 
a) Traffic-engineering architectures for generic applicability
across packet and non-packet networks. This includes, for example,
networks that perform centralized computation and control, in conformance
with ACTN (and PCE) principles as well as distributed computation and 
control. The use of PCEP is optional and the PCE architecture itself
is out of the WG scope.

Call to the wordsmiths in the WG to further refine! :)

I wanted to differentiate between PCE (entity that does path computation) and the PCEP (protocol). 
"..ACTN principles but don't make use of PCE" was the main issue! 

Hope this helps! 

Regards,
Dhruv


--
Dhruv Dhody 
Lead Architect
Network Business Line
Huawei Technologies India Pvt. Ltd.
Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield
Bengaluru, Karnataka - 560066 
Tel: + 91-80-49160700 Ext 71583 II Email: [e-mail]

This e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use of the 
information contained herein in any way (including, but not limited to, total or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
phone or email immediately and delete it!


> -----Original Message-----
> From: Teas [mailto:[e-mail]] On Behalf Of Lou Berger
> Sent: 10 October 2018 22:45
> To: Dhruv Dhody <[e-mail]>
> Cc: TEAS WG Chairs <[e-mail]>; TEAS WG <[e-mail]>
> Subject: Re: [Teas] Proposed charter update
> 
> Dhruv,
> 
> you made the following comment on the google doc:
> 
> > *Dhruv Dhody*
> >
> > This should convey that both centralized (controller) and distributed
> > TE is in scope. And then use of "PCEP" is optional in the controller.
> > I dont think that is clear with this text.
> >
> Do you have any specific text proposals to address your concern?
> 
> Thanks,
> 
> Lou
> 
> 
> On 10/8/2018 2:49 AM, Vishnu Pavan Beeram wrote:
> > Hi,
> >
> > Over the past few months we've noted that our charter could use a bit
> > of an update to match the current state of TEAS and other working groups.
> > We've taken a pass at this and have a proposed revision.  Once the WG
> > agrees on changes, we'll pass those changes along to our AD who is the
> > actual owner of our charter.  The text is enclosed below as well as
> > available with changes tracked at:
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_d
> > ocument_d_1l5y3nH3KmOQbHOMp-5FRFm1SK5riS5qi1klve-2D-2DkyUbSU_edit-3Fus
> > p-3Dsharing&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=C
> > FHVfW0WsgxSqM6wTJiWE5evUJAdlUl1fm7E0WVbiS8&m=6pI1yDFJYCLr4YBDXOEJFxWzJ
> > QMmsW5q1X0ic60qgM4&s=XHgp3ISuFZZj_FUiGKK2ZjRndlSyIxgomtfqyEt3DRU&e=
> >
> > Please discuss any proposed changes on the list, i.e., changes to the
> > charter that are suggested in the google-doc but not agreed to here
> > will be ignored.
> >
> > We'd like to have the changes agreed to by the end of this month so
> > the IESG may have time to review/act before  IETF103.
> >
> > Thank you,
> > Pavan and Lou
> >
> > --
> > Draft Update to TEAS WG Charter (Version 1)
> >
> > The Traffic Engineering Architecture and Signaling (TEAS) Working
> > Group is responsible for defining IP, MPLS and GMPLS traffic
> > engineering architecture and identifying required related
> > control-protocol functions, i.e., routing and path computation element
> > functions. The TEAS group is also responsible for standardizing
> > generalized, i.e., non-technology specific, RSVP-TE signaling protocol
> > mechanisms,
> >
> > 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, but may also be provided by other mechanisms such as
> > forwarding rules similar to policy-based routing. 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. Centralized and logically centralized control models are
> > also supported, e.g., via Abstraction and Control of Traffic
> > Engineered Networks (ACTN) and stateful-PCE.
> >
> >  The TEAS WG is responsible for:
> >
> >    a) Traffic-engineering architectures for generic applicability
> > across packet and non-packet networks.. This includes, for example,
> > both networks that include the use of PCE and those that conform with
> > ACTN principles but don't make use of PCE. 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), including those that 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 in support of Traffic Engineering, 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 LSR (OSPF and ISIS) WG to maintain or extend TE routing
> > mechanisms.
> >
> >    - 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.
> >
> >    - With the DetNet WG on mechanisms (YANG models and protocols) to
> > support DetNet use cases.
> >
> >    - With the SPRING WG on TE architecture and, where appropriate,
> > TE-related protocol extensions.
> >
> > In doing this work, the WG will cooperate with external SDOs (such as
> > the ITU-T and the IEEE 802.1) as necessary.
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Teas mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/teas
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas