Oscar;
Comments in-line;
In the case of current Working Group stateful PCE solution
> (draft-ietf-pce-stateful-pce-02), the focus is mainly on the new functions
> to be supported: Capability Negotiation, State Synchronization, LSP State
> Report , LSP Control Delegation, LSP Update Request, etc All these set of
> functions are independent whether it is a MPLS-TE or a GMPLS tunnel. Thus,
> I don't see why the scope should be limited to MPLS-TE.
Thank you very much for being specific about which draft you are referring
to! The framework draft, draft-ietf-pce-stateful-pce-02, is obviously NOT
limited to MPLS-TE. This draft is intended to support extensions for
MPLS-TE, GMPLS and other potential extensions going forward. This has been
the case from the beginning. Please see my previous email about the
/framework/ draft supporting MPLS-TE & GMPLS as well as the several off
list discussions we've had regarding same. An (re)illustration of the
proposed document set relationships is included below:
applicability draft
|
|
core framework draft
|
|
/|\
____/ | \____
/ | \
/ | RSVP-TE
/ |
/ |
GMPLS |
|
other extensions
note that this is *not* a timeseries. :P
> Would those functions be different in GMPLS and needed separate messages
> and objects, I would agree in separating the solution. For example, in the
> current draft, there are very few objects which are MPLS-TE specific.
That is intentional. Again, you are referring to the framework draft,
which was intended to support both from the beginning.
AFAIK we are discussing the separate extension drafts. If we are NOT
discussing the separate extensions draft then we are in violent agreement:
the framework should, and does support both.
> I have gone through the document several times to see the points which
> could be different in GMPLS, and I could not find them (maybe I miss
> something here, so If you think the number of specific MPLS-TE /GMPLS
> objects will be significant, please give the examples). All the new
> messages apply for both MPLS-TE and GMPLS, without the need of any change.
>
Yes, this was deliberate. Please see my previous email in the thread
regarding extension vs framework.
> For other applications of the stateful PCE, GMPLS and MPLS-TE may
> go in separate documents if there are many differences between them, and
> the documents are cleaner with separate extensions.
>
> "(in fact this is the case for Google; as a company we do not care about
> GMPLS, we /do/ very much care about MPLS-TE.) "
>
> Sorry, Ed, but the argument of a specific company position of what
> cares or not is by no means acceptable. Please, limit the arguments to
> technical and not political.
>
Oh, I agree that the specific google instance has no bearing here; this
isn't a political argument and is true no matter what company we're talking
about, vendor or customer. The longer form of the argument is as follows:
If you combine the *extension* drafts, you end up with both features being
glommed together in one spec. If a specific vendor is in one market or the
other and does not require the full spec, OR a specific customer has need
of only one of the two and is pushing a vendor to implement it, combining
the two into a single draft either adds additional work in unnecessarily
implementing both or potentially increases the difficulty for the
implementor in disentangling the two and claiming RFC compliance. Having
separate *extension* drafts inherently provides the split that exists the
two markets in reality.
best,
-ed
________________________________
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
