Re: [Teas] 答复: 答复: Proposed charter update

[Aijun Wang <[e-mail]>]

Hi，Lou:

I agree and understand the current modification. Thank you.

Aijun Wang
China Telecom

> 在 2018年10月17日，19:17，Lou Berger <[e-mail]> 写道：
> 
> Aijun,
> 
> Please see below...
> 
> 
> 
> ----------
> On October 16, 2018 9:47:35 PM "Aijun Wang" <[e-mail]> wrote:
> 
> > Hi, Lou:
> >
> >  
> >
> > I refines the related descriptions for clarification. Please see whether they are more accurate or not.
> >
> >  
> >
> > Best Regards.
> >
> >  
> >
> > Aijun Wang
> >
> > Network R&D and Operation Support Department
> >
> > China Telecom Corporation Limited Beijing Research Institute,Beijing, China.
> >
> >  
> >
> > 发件人: Lou Berger [mailto:[e-mail]] 
> > 发送时间: 2018年10月15日 22:50
> > 收件人: Aijun Wang; 'Vishnu Pavan Beeram'; 'TEAS WG'; 'TEAS WG Chairs'
> > 主题: Re: [Teas] 答复: Proposed charter update
> >
> >  
> >
> >  
> >
> > Hi Aijun,
> >    Thank you for the comments.  Please see below for responses in-line.
> >
> >
> >
> > On 10/11/2018 9:55 PM, Aijun Wang wrote:
> >
> > 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:[e-mail]] 
> > 发送时间: 2018年10月8日 14:50
> > 收件人: TEAS WG; TEAS WG Chairs
> > 主题: [Teas] Proposed charter update
> >
> >  
> >
> > 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 <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.
> >
> > 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,
> >
> > [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.
> 
> 
> >
> >
> >
> >
> > 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.
> >
> > [Aijun Wang]: Is it more concise here to say “Centralized control 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]: 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
> > Networks (ACTN) and stateful-PCE.”
> >
> 
> 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.
> 
> >
> >
> >
> >
> >
> >
> >  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.
> >
> > [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]: Ok, maybe I am confused by them.
> >
> 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
> 
> 
> >
> >
> >
> >
> >    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.
> >
> > [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] 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.
> 
> 
> >
> >
> >
> >    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.
> >
> >
> >
> >
> > [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"?
> >
> > [Aijun Wang]: OK. But it should be “…for TE path and tunnel control”.?
> 
> 
> 
> Yes, that was a typo.
> 
> 
> >
> >
> >   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.
> >
> > [Aijun Wang]: Is it more generalized to replace “end-point protection” with “TE-path and TE-tunnel protection”?
> >
> > These are just examples.  How about: "including, for example, ..."?
> >
> > [Aijun Wang]:  The revised description style will be more clear and extensible.
> >
> 
> 
> 
> Thanks again
> Lou
> 
> >
> > Thank you again for the feedback!
> > Lou
> >
> >
> >
> >
> >
> >    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
> >
> >  
> >