Subject: [Teas] Proposed charter update

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 8 Oct 2018 02:49:37 -0400

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_document_d_1l5y3nH3KmOQbHOMp-5FRFm1SK5riS5qi1klve-2D-2DkyUbSU_edit-3Fusp-3Dsharing&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CFHVfW0WsgxSqM6wTJiWE5evUJAdlUl1fm7E0WVbiS8&m=6pI1yDFJYCLr4YBDXOEJFxWzJQMmsW5q1X0ic60qgM4&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.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 9 Oct 2018 09:53:53 -0400

Pavan and Lou,

The proposed update looks good, especially with the inclusion of DetNet.
However, support for DetNet should be more general than just support for
"use cases", which could be interpreted to be limited to those in the
forthcoming DetNet Use Cases RFC. Rather, how about:

 - With the DetNet WG on mechanisms (YANG models and protocols) to support
the DetNet architecture and forwarding plane.

Also, something else occurs to me that is somewhat more speculative and may
actually not fit, but I'll mention it anyway. While SFC doesn't require
traffic engineering in terms of bandwidth guarantees, it does require the
ability to establish constrained (policy-based) paths in terms of the
ordering of nodes for a particular flow or chain, and TEAS certainly has a
lot of experience with signaling protocols to establish constrained paths.
So perhaps there's some coordination with the SFC WG that may make sense
there. Just a thought.

Cheers,
Andy

On Mon, Oct 8, 2018 at 2:49 AM Vishnu Pavan Beeram <[email-masked]>
wrote:

> charter that are suggested in the google-doc but not agreed to here will
> be ignored.
>
> across packet and non-packet networks.. This includes, for example, both
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: Lou Berger <[email-masked]>
Date: Tue, 9 Oct 2018 12:49:02 -0400

Hi Andy,

On 10/9/2018 9:53 AM, Andrew G. Malis wrote:
> Pavan and Lou,
>
> The proposed update looks good, especially with the inclusion of 
> DetNet. However, support for DetNet should be more general than just 
> support for "use cases", which could be interpreted to be limited to 
> those in the forthcoming DetNet Use Cases RFC. Rather, how about:
>
well it says "use cases" not "Use Cases", but...
> support the DetNet architecture and forwarding plane.
How about:
support DetNets

>
> Also, something else occurs to me that is somewhat more speculative 
> and may actually not fit, but I'll mention it anyway. While SFC 
> doesn't require traffic engineering in terms of bandwidth guarantees, 
> it does require the ability to establish constrained (policy-based) 
> paths in terms of the ordering of nodes for a particular flow or 
> chain, and TEAS certainly has a lot of experience with signaling 
> protocols to establish constrained paths. So perhaps there's some 
> coordination with the SFC WG that may make sense there. Just a thought.

Fair enough, how about:
- With the SFC WG on mechanisms (YANG models and protocols) to support SFCs

Lou
>
> Cheers,
> Andy
>
>
>
> On Mon, Oct 8, 2018 at 2:49 AM Vishnu Pavan Beeram 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     charter that are suggested in the google-doc but not agreed to
>     here will be ignored.
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 9 Oct 2018 15:02:09 -0400

Lou,

Both look great, thanks!

Cheers,
Andy

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 9 Oct 2018 21:35:20 -0400

Andy, Hi!

Thanks for the comments! We do have a couple of TEAS WG documents that are
of interest to the SFC WG.

The Google doc has been updated to reflect the changes.

Regards,
-Pavan

On Tue, Oct 9, 2018 at 9:54 AM Andrew G. Malis <[email-masked]> wrote:

> Also, something else occurs to me that is somewhat more speculative and
> may actually not fit, but I'll mention it anyway. While SFC doesn't require

---

From: Lou Berger <[email-masked]>
Date: Wed, 10 Oct 2018 13:14:54 -0400

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:
> charter that are suggested in the google-doc but not agreed to here 
> will be ignored.
>

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 12 Oct 2018 09:55:25 +0800

Hi, Vishnu and Lou:

I have the following suggestions(inline) for the charter, please see whether they are appropriate or not?

Best Regards.

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

发件人: Vishnu Pavan Beeram [mailto:[email-masked]] 
发送时间: 2018年10月8日 14:50
收件人: TEAS WG; TEAS WG Chairs
主题: [Teas] Proposed charter update

Hi,

https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1l5y3nH3KmOQbHOMp-5FRFm1SK5riS5qi1klve-2D-2DkyUbSU_edit-3Fusp-3Dsharing <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1l5y3nH3KmOQbHOMp-5FRFm1SK5riS5qi1klve-2D-2DkyUbSU_edit-3Fusp-3Dsharing&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CFHVfW0WsgxSqM6wTJiWE5evUJAdlUl1fm7E0WVbiS8&m=6pI1yDFJYCLr4YBDXOEJFxWzJQMmsW5q1X0ic60qgM4&s=XHgp3ISuFZZj_FUiGKK2ZjRndlSyIxgomtfqyEt3DRU&e=> &d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CFHVfW0WsgxSqM6wTJiWE5evUJAdlUl1fm7E0WVbiS8&m=6pI1yDFJYCLr4YBDXOEJFxWzJQMmsW5q1X0ic60qgM4&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.

Thank you,
Pavan and Lou

[Aijun Wang]: Is it more suitable to say “non-domain specific” instead of “non-technology specific” ? I guess the author may mention that RSVP-TE can be used in packet and non-packet network here.

[Aijun Wang]: Is it more concise here to say “Centralized control model are also supported”?

[Aijun Wang]: Is there any situation that conform with ACTN principles but don’t’ make use of PCE? Is it more generalized to say “This includes, for example, both networks that include the use of PCE or not”?

[Aijun Wang]: Is it more accurate to say “Functional specification of extensions for routing (OSPF, ISIS) and for path computation protocol (PCEP),..”

[Aijun Wang]: Is it more accurate to say “Definition and extension of management and security techniques for TE path and TE tunnels signaling….”, instead of only mentioning the “RSVP-TE signaling”?

[Aijun Wang]: Is it more generalized to replace “end-point protection” with “TE-path and TE-tunnel protection”?

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 12 Oct 2018 05:01:06 +0000

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

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:[email-masked]] On Behalf Of Lou Berger
> Sent: 10 October 2018 22:45
> To: Dhruv Dhody <[email-masked]>
> Cc: TEAS WG Chairs <[email-masked]>; TEAS WG <[email-masked]>
> Subject: Re: [Teas] Proposed charter update
> 
> Dhruv,
> 
> > 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.
> > 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=
> >
> > 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
> >
> > --
> > 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,
> >
> > 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.
> >
> > 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.
> >
> > signaling and path computation). These will be developed in
> > conjunction with requests and requirements from other WGs to ensure
> > overall usefulness.
> >
> > 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.
> >
> > technology-specific) extensions for RSVP-TE, and the associated
> > protocol formats and procedures that embody these extensions.
> >
> > 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.
> >
> > 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.
> >
> > advertise these properties, and extensions to RSVP-TE to request and
> > to accumulate these properties. Work with PCE WG to include these
> > requirements for abstraction and distribution of TE information
> > between interconnected TE domains/layers.
> >
> > mechanisms including end-point protection, protection of P2MP LSPs,
> > and inter-domain protection.
> >
> > with working groups working on YANG models for network topology and
> > for technology-specific network attributes.
> >
> > technology-specific TE protocol mechanisms and to determine whether
> > they should be generalized.
> >
> > architecture, on PCE extensions per the above, and on RSVP-TE
> > extensions to support PCE WG identified requirements.
> >

---

From: Lou Berger <[email-masked]>
Date: Mon, 15 Oct 2018 10:50:09 -0400

Hi Aijun,
    Thank you for the comments.  Please see below for responses in-line.

On 10/11/2018 9:55 PM, Aijun Wang wrote:
> *发件人:*Vishnu Pavan Beeram [mailto:[email-masked]]
> *发送时间:*2018年10月8日14:50
> *收件人:*TEAS WG; TEAS WG Chairs
> *主题:*[Teas] Proposed charter update
>
> Hi,
>
> [Aijun Wang]: Is it more suitable to say “non-domain specific” instead 
> of “non-technology specific” ? I guess the author may mention that 
> RSVP-TE can be used in packet and non-packet network here.
>
How about:
   The TEAS group is also responsible for standardizing RSVP-TE 
signaling protocol mechanism that are not related to a specific 
switching technology.

> model are also supported”?

It may be more concise, but I think it is less clear so would prefer to 
leave as is.

> [Aijun Wang]: Is there any situation that conform with ACTN principles 
> but don’t’ make use of PCE? Is it more generalized to say “This 
> includes, for example, both networks that include the use of PCE or not”?
>
I don't believe ACTN requires use of PCE so I think the current text 
covers such cases while the proposed revision does not.

> [Aijun Wang]: Is it more accurate to say “Functional specification of 
> extensions for routing (OSPF, ISIS) and for path computation _protocol 
> (PCEP)_,..”
>
I'm not sure, I really don't see any difference in the language.

Rereading this that it should say "may also use RSVP-TE".

> [Aijun Wang]: Is it more accurate to say “Definition and extension of 
> management and security techniques for TE path and TE tunnels 
> signaling….”, instead of only mentioning the “RSVP-TE signaling”?
>
This is a fair point.  How about "...for TP path and tunnel control"?

> with “TE-path and TE-tunnel protection”?
These are just examples.  How about: "including, for example, ..."?

Thank you again for the feedback!
Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 15 Oct 2018 10:59:17 -0400

Hi Dhruv,

> "..ACTN principles but don't make use of PCE" was the main issue!

ACTN and PCE are different things?  IAs I see it, it's possible to have 
a controller that follows ACTN but not PCE (as embodied in the related 
RFCs).  I think your point is that one that does this is still following 
PCE *principles* -- do I understand correctly?  If so, I think this is a 
very subtle point and perhaps, we can side step this as follows:

a) Traffic-engineering architectures for generic applicability
      across packet and non-packet networks. This includes, for example,
      networks that perform centralized computation and control,
      distributed computation and control, or even a hybrid approach.

What do you think?

Thanks,
Lou

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 15 Oct 2018 21:21:13 +0530

Hi Lou,

> PCE *principles* -- do I understand correctly?

Yes, IMHO even when yang is being used in ACTN, the controllers still
implement the PCE functions (without the use of PCEP).

> If so, I think this is a

But, this side stepping is perfectly fine!

Thanks!
Dhruv

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 17 Oct 2018 09:46:53 +0800

Hi, Lou:

I refines the related descriptions for clarification. Please see whether they are more accurate or not.

Best Regards.

Aijun Wang

发件人: Lou Berger [mailto:[email-masked]] 
发送时间: 2018年10月15日 22:50
收件人: Aijun Wang; 'Vishnu Pavan Beeram'; 'TEAS WG'; 'TEAS WG Chairs'
主题: Re: [Teas] 答复: Proposed charter update

Hi Aijun,

Hi, Vishnu and Lou:

 

Best Regards.

Aijun Wang

Hi,

Thank you,
Pavan and Lou

How about:
  The TEAS group is also responsible for standardizing RSVP-TE signaling protocol mechanism that are not related to a specific switching technology.

[Aijun Wang]: Would it more clear to say “The TEAS group is also responsible for standardizing RSVP-TE signaling protocol mechanism that can be used in packet and non-packet(optical) network.” ?

It may be more concise, but I think it is less clear so would prefer to leave as is.

[Aijun Wang]: From the context, we can know the sentence “RSVP-TE is the signaling protocol used for both MPLS-TE and GMPLS.” mainly focuses on the distributed control mode, then it is naturally to add the latter description for “centralized control mode”.  My arguments here is that what is the “logically centralized control models?”,  Is it redundant for us to say it? I still think the following description is enough:

“RSVP-TE is the signaling protocol used for both MPLS-TE and GMPLS. Centralized models are also supported, e.g., via Abstraction and Control of Traffic Engineered
Networks (ACTN) and stateful-PCE.”

I don't believe ACTN requires use of PCE so I think the current text covers such cases while the proposed revision does not.

[Aijun Wang]: Ok, maybe I am confused by them.

[Aijun Wang] Here we mainly want to say TEAS WG is responsible for the extension of the protocols that are related to the traffic engineering requirements. PCE is not protocol, instead PCEP is the protocol needs to be extended.

[Aijun Wang]: OK. But it should be “…for TE path and tunnel control”.?

[Aijun Wang]:  The revised description style will be more clear and extensible.

---

From: Lou Berger <[email-masked]>
Date: Wed, 17 Oct 2018 07:17:14 -0400

Aijun,

Please see below...

----------
On October 16, 2018 9:47:35 PM "Aijun Wang" <[email-masked]> wrote:

> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1l5y3nH3KmOQbHOMp-5FRFm1SK5riS5qi1klve-2D-2DkyUbSU_edit-3Fusp-3Dsharing 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1l5y3nH3KmOQbHOMp-5FRFm1SK5riS5qi1klve-2D-2DkyUbSU_edit-3Fusp-3Dsharing&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CFHVfW0WsgxSqM6wTJiWE5evUJAdlUl1fm7E0WVbiS8&m=6pI1yDFJYCLr4YBDXOEJFxWzJQMmsW5q1X0ic60qgM4&s=XHgp3ISuFZZj_FUiGKK2ZjRndlSyIxgomtfqyEt3DRU&e=> 
> &d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CFHVfW0WsgxSqM6wTJiWE5evUJAdlUl1fm7E0WVbiS8&m=6pI1yDFJYCLr4YBDXOEJFxWzJQMmsW5q1X0ic60qgM4&s=XHgp3ISuFZZj_FUiGKK2ZjRndlSyIxgomtfqyEt3DRU&e=
>
> [Aijun Wang]: Is it more suitable to say “non-domain specific” instead of 
> “non-technology specific” ? I guess the author may mention that RSVP-TE can 
> be used in packet and non-packet network here.
>
> How about:
>   The TEAS group is also responsible for standardizing RSVP-TE signaling 
>   protocol mechanism that are not related to a specific switching technology.
>
>
>
> [Aijun Wang]: Would it more clear to say “The TEAS group is also 
> responsible for standardizing RSVP-TE signaling protocol mechanism that can 
> be used in packet and non-packet(optical) network.” ?
>

For me, this less precise/clear so prefer either the original or revised 
versions.

> [Aijun Wang]: From the context, we can know the sentence “RSVP-TE is the 
> signaling protocol used for both MPLS-TE and GMPLS.” mainly focuses on the 
> distributed control mode, then it is naturally to add the latter 
> description for “centralized control mode”.  My arguments here is that what 
> is the “logically centralized control models?”,  Is it redundant for us to 
> say it?

Strictly speaking a centralized controller translates to a single entity. 
There are many sdn architectures that use multiple controllers and the term 
logically centralized has been used to refer to these. Neither of the 
models use RSVP.

> I still think the following description is enough:
>
> “RSVP-TE is the signaling protocol used for both MPLS-TE and GMPLS. 
> Centralized models are also supported, e.g., via Abstraction and Control of 
> Traffic Engineered

in my experience  when one just says centralized control, the distributive 
form of SDN control is overlooked or considered out of scope, so I think 
it's important to include that case.

> [Aijun Wang]: Is there any situation that conform with ACTN principles but 
> don’t’ make use of PCE? Is it more generalized to say “This includes, for 
> example, both networks that include the use of PCE or not”?
>
> I don't believe ACTN requires use of PCE so I think the current text covers 
> such cases while the proposed revision does not.
>
This got revised based on discussion with Dhruv. Take a look at the new 
text, in email or on Google, and some comments if you have them

> extensions for routing (OSPF, ISIS) and for path computation protocol 
> (PCEP),..”
>
> [Aijun Wang] Here we mainly want to say TEAS WG is responsible for the 
> extension of the protocols that are related to the traffic engineering 
> requirements. PCE is not protocol, instead PCEP is the protocol needs to be 
> extended.
>

Ahh. Thank you for the clarification, I'll make the change.

> management and security techniques for TE path and TE tunnels signaling….”, 
> instead of only mentioning the “RSVP-TE signaling”?
>

Yes, that was a typo.

> [Aijun Wang]:  The revised description style will be more clear and extensible.

Thanks again
Lou

---

From: Aijun Wang <[email-masked]>
Date: Wed, 17 Oct 2018 21:25:31 +0800

Hi，Lou:

I agree and understand the current modification. Thank you.

Aijun Wang
China Telecom

> 在 2018年10月17日，19:17，Lou Berger <[email-masked]> 写道：
> 
> Aijun,
> 
> Please see below...
> 
> 
> 
> ----------
> For me, this less precise/clear so prefer either the original or revised versions.
> 
> 
> >
> >
> >
> >
> > [Aijun Wang]: From the context, we can know the sentence “RSVP-TE is the signaling protocol used for both MPLS-TE and GMPLS.” mainly focuses on the distributed control mode, then it is naturally to add the latter description for “centralized control mode”.  My arguments here is that what is the “logically centralized control models?”,  Is it redundant for us to say it?
> 
> Strictly speaking a centralized controller translates to a single entity. There are many sdn architectures that use multiple controllers and the term logically centralized has been used to refer to these. Neither of the models use RSVP.
> 
> >
> 
> in my experience  when one just says centralized control, the distributive form of SDN control is overlooked or considered out of scope, so I think it's important to include that case.
> 
> >
> >
> >
> >
> >
> >
> This got revised based on discussion with Dhruv. Take a look at the new text, in email or on Google, and some comments if you have them
> 
> 
> >
> >
> >
> >

---

From: Lou Berger <[email-masked]>
Date: Fri, 26 Oct 2018 09:59:55 -0400

Hi,

The discussion on the charter seems to have closed.  The plan is for us 
(chairs) to summarize the changes in Bangkok, and then get the changes 
approved by the IESG.  As charters are actually owned by the AD, Deborah 
will be the one moving the proposed revision through  this process.

The version that resulted from the  discussion is:

     Draft Update to TEAS WG Charter

     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 RSVP-TE signaling protocol
     mechanisms that are not related to a specific switching
     technology.

      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.

        a) Traffic-engineering architectures for generic
           applicability across packet and non-packet
           networks. This includes, for example, networks that
           perform centralized computation and control, distributed
           computation and control, or even a hybrid approach.

        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 (PCEP), including
           those that provide general enablers of
           traffic-engineering systems that may 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 for TP path and tunnel control. 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.

        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, for example, 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 DetNet WG on mechanisms (YANG models and
          protocols) to support DetNets.

        - With the SPRING WG on TE architecture and, where
          appropriate, TE-related protocol extensions.

        - With the SFC WG on mechanisms (YANG models and protocols) to
          support SFCs

       In doing this work, the WG will cooperate with external SDOs
       (such as the ITU-T and the IEEE 802.1) as necessary.

The changes from the discussion can be found at:

https://docs.google.com/document/d/1l5y3nH3KmOQbHOMp_RFm1SK5riS5qi1klve--kyUbSU/edit?ts=5bc7216c

Lou (and Pavan)

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 26 Oct 2018 15:20:19 +0000

Hi Lou, 

Thanks for the update of the charter. 

In the charter the definition of TE is: "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 "

One questions I'd like to ask is what is the relationship between TE and QoS? RSVP-TE was defined for both explicit path control and bandwidth reservation, in which the bandwidth reservation mechanism follows the Int-Serv QoS mode. Although currently DiffServ is widely used due to its simplicity and scalability, it is not clear whether Diff-Serv is good enough for the emerging or future applications. Thus I'd like to know whether future work about resource reservation and possible extensions related to Int-Serv/Diff-Serv QoS modes will be in the scope of TEAS charter?

Best regards,
Jie

> -----邮件原件-----
> 发件人: Teas [mailto:[email-masked]] 代表 Lou Berger
> 发送时间: 2018年10月26日 22:00
> 收件人: Vishnu Pavan Beeram <[email-masked]>; TEAS WG
> <[email-masked]>; TEAS WG Chairs <[email-masked]>
> 主题: Re: [Teas] Proposed charter update
> 
> Hi,
> 
> approved by the IESG.  As charters are actually owned by the AD, Deborah will
> be the one moving the proposed revision through  this process.
>