Hi Tomo,
I read your draft pointed by Dan that indeed contains some valuable
information.
Especially in section 2.2:
"For the simplicity of the analysis in path consideration, the below
basic assumptions are made when the LSP is created.
(1) Switching capabilities (SC) of outgoing links from the
ingress and egress nodes (link1-2 and link4-3 in Figure 1)
must be consistent with each other.
(2) SC of all transit links including incoming links to the
ingress and egress nodes (link2-1 and link3-4) should be
consistent with switching type of a LSP to be created.
(3) Encoding-types of all transit links should be consistent
with encoding type of a LSP to be created."
Point 2 and 3 seems to imply that a PCE needs to know both the switching and
encoding type
of the LSP.
To me the information would typically be provided by the PCC (which knows
what kind of LSP is being established)
using PCEP.
Am I misunderstanding something or do you agree?
Regards
Fabien
----- Original Message -----
From: "Tomohiro Otani" <[EMAIL PROTECTED]>
To: "Adrian Farrel" <[EMAIL PROTECTED]>
Cc: "fabien.verhaeghe" <[EMAIL PROTECTED]>; "LE ROUX
Jean-Louis RD-CORE-LAN" <[EMAIL PROTECTED]>; "Dan Li"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, March 30, 2007 1:44 AM
Subject: Re: [Pce] Switching type Constraint in PCEP
Hi Fabien and Adrian,
Looking at the discussion, path computation itself and a protocol
staff such as PCEP are a different thing. I believe, touch upon
by Dan, that our cspf draft is a kind of guideline how to consider
GMPLS-specific constrains including encoding type for path computation.
I hope that the cspf draft help Fabien to understand parameters.
If you need any help for GMPLS specific extensions, please let me know.
With best regards,
Tomo
Adrian Farrel wrote:
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
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
