Hello,
Speaking as an individual contributor...
I like Ed's picture, but I would offer an insert *if* it is possible. Maybe
there is a generic extensions document to be broken out and inserted in the
picture below "core framework draft" and before the fork into the various
targeted extensions drafts.
This might be over-cooking the problem because the generic could be included in
the first targeted extensions draft, and those could make reference. However,
consider poor old Ed having to point at a GMPLS-specific document in order to
tell his MPLS-TE vendor what to implement.
I appreciate that it is not always possible to consider the generic when there
is only one specific use case. But here we know that there are two in the pipe
so we can at least give some thought to it.
A
From: [email protected] [mailto:[email protected]] On Behalf Of Edward
Crabbe
Sent: 26 October 2012 13:23
To: Oscar González de Dios
Cc: [email protected]
Subject: Re: [Pce] 答复: stateful PCE - moving forward & next steps
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
[email protected]
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
