Subject: Splitting TE Architecture from protocol work

From: OSCAR GONZALEZ DE DIOS <[email-masked]>
Date: Fri, 22 Aug 2014 10:11:07 +0000

Hi all,

I have also just joined the discussions per Lou's mail to ccamp and gone through the mail archive, which I've found very interesting and constructive.

One of the concerns that has been raised and shared by several people is the risk associated to splitting the architecture from the protocol work. One the one hand, in a very well narrowed down scope, having both in the same place works well (and produces nice running code). Of course, no friction among architecture and protocol work (same people) However, when the scope is wider and the work needed is so big, there is a big risk, that WG contributors focus on one WG, don't care about the others and repeated work and inconsistencies appear.

A very good example is PCE and CCAMP (or MPLS for the packet world). Work in CCAMP has avoided for a long time to deal with PCE, just because it was in a different WG. This leads to having problems which are solved taking into account only part of the pieces in the equation. For example, one of the latest discussed problems is the interconnection of TE domains. For a many signaling and path computation had their own solutions, with an unclear relation between them. Lately, Adrian's draft to tackle that problem included considerations about path computation, with very good criteria. And it needs also to consider the dissemination of Traffic Engineering in the equation, adding more meat.. and thus needing to consider routing protocols.

Summing up, from my very humble point of view, having a joint approach in the architecture for Traffic Engineering, in which signaling, path computation and routing are considered together, is positive and gives consistency. I fully support Lou's view on the need of consistency. A different question is how much work is needed just for this. Mechanisms, and the protocol extensions needed to support the mechanisms,  should be dealt in specific WGs (as they are now).

I just wonder what happens in the case of a mechanism that needs to enhance functionalities in protocols of two different WGs. Will that lead to three documents, one in TEAS, and one per protocol-specific extension?

Regarding the possible content of TEAS, in addition to the architecture work, can be home to informational RFCs / BCPS in which use cases using mechanisms of different protocols are explained.

Óscar

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Leeyoung <[email-masked]>
Date: Fri, 22 Aug 2014 14:56:49 +0000

Hi all,

If TEAS WG were to be separated from protocol work, then how would a new architecture work (that requires protocol extension) proceed? Would TEAS have to approve (adopt) this new work before this can be addressed in other WGs that are responsible for protocol extension? Else, would this work be addressed in parallel in other WGs concurrently? If the former is true, certain works will take a long time to be a standard although there are other merits (as Oscar elaborated) to have TEAS focus on architecture issues that deserve more time and discussion.

This cross-WG relations should be understood more clearly.

It would also be good if we understand the draft charter of new WGs as well as existing WGs that are affected with this reorganization.

Young

From: routing-discussion [mailto:[email-masked]] On Behalf Of OSCAR GONZALEZ DE DIOS
Sent: Friday, August 22, 2014 5:11 AM
To: [email-masked]
Subject: Splitting TE Architecture from protocol work

Hi all,

Óscar