Hi Fabien,
Reading the generic and inter layer requirement documents it is not clear
to me if Switching Type is really specific to inter layer application.
As far as I understand inter-layer requirement refers to path computation
which result path may comprise multiple layer technologies.
Though I understand Switching type is required in this context, it is also
required for mono layer path computation in a multi-layer environment
(e.g. to computate a Lambda path using a TE Database that contains also
TDM TE Links).
So it is more a GMPLS specific requirement to me.
I think you are correct. That is, the switching type constraint is required
in the multi-layer context, but it may have wider applicability.
Provided that the multi-layer work progress quite quickly, I would suggest
that it is convenient to group all of the protocol extensions together. You
can then select from the set of optional objects as necessary for your
application. I would hope that you would provide your review input to the
multi-layer work to ensure that the protocol extensions give you what you
need.
On the other hand, if the multi-layer work seems to get stuck or held up,
then I would understand you pushing to get the "GMPLS-specific" extensions
done separately.
Acually it is not clear to me what is the scope of generic and
"application specific" requirements. Generic Requirement RFC4657 section
5.1.16
mention Switching and encoding type as "GMPLS specific requirements".
Does it mean "GMPLS specific" is "considered as generic?
Hmmm.
This is a line we have not succeeded in drawing very clearly.
However, where we seem to have arrived is that the PCEP I-D contains the
protocol definition and "core" functional units. Other units that were
identified in 4657 (such as XRO, objective funcions, ...) are going into
seperate I-Ds. Following that model, the GMPLS-specific work definitely goes
into a separate draft. As above, I am comfortable for that to be in the
multi-layer I-D (perhaps we re-name to "GMPLS and multi-layer"?) to help
keep the number of I-Ds manageable.
Concerning the necessity of "encoding type" in PCEP I have to admit that
I'm not sure to correctly understand the meaning of this parameter in the
GMPLS
architecture :-).
I think this puts you in the majority!
What I understand at least is that it is both an interface and
an LSP property, so from this it seems to be required in PCEP.
I would be interested to see discussion about encoding type
requirement in PCEP cause it may clarify the encoding type meaning to me
;-).
So my view (other will surely correct me :-) is that encoding type is only
needed where the signal is unpacked for some reason. Typically, this only
happens at end points, so the PCE function is to ensure that the destination
interface is capable of decoding the signal and delivering the data. In
general, it has been considered that the destination capabilities are either
known to the ingress (guaranteed LSP setup success - you wouldn't even
bother trying to set up an LSP to someone you knew couldn't understand you)
or are not known in which case the LSP will either succeed or fail (but no
amount of re-routing will help). Now, it *is* possible that different
interfaces on the egress have different levels of support for encoding
types, but this has generally been considered as very advanced and not worth
optimising for.
However, recent discussion has suggested that in certain technologies,
signal regeneration also requires knowledge of the encoding type. This would
certainly expand the requirement for PCE to know about encoding type. I am
not sure about the hardware specifics here and perhaps someone can enlighten
us.
Cheers,
Adrian
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
