hi jean-louis, much thanks for your reply and suggestions, see in-line
LE ROUX Jean-Louis RD-CORE-LAN wrote:
Hi Dimitri and all,
Thanks a lot for these really useful comments Please see inline
-----Message d'origine----- De : Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be] Envoyé : jeudi 22 juillet 2004
20:43 À : Adrian Farrel Cc : ccamp@ops.ietf.org; 'Jean Philippe Vasseur';
LE ROUX Jean-Louis RD-CORE-LAN Objet : Re:
draft-vasseur-ccamp-te-router-info-00
hi adrian, all,
here below a bunch of comments on this documents:
=> 3. Introduction
- Data plane capabilities related to the node itself and not to its
links, such as the capability to be a branch node or a bud LSR of a P2MP
LSP tunnel (see [P2MP-REQ]). These node capabilities should be advertised
by the IGP for path selection. It would also be highly useful to
advertise control plane node Capabilities; for instance, the capability
to support GMPLS signaling for a packet LSR, or the capability to
support P2MP signaling. This would ease backward compatibility. For
instance this would allow selecting a path that would avoid nodes that do
not support a given signaling feature, or automatically triggering a
mechanism that would handle these nodes on the path.
[DP] suggest to translate the protocol specific also within the above text
with something like
- Nodal capabilities
1) control plane
2) data plane
In 4.2 we define two distinct pieces of Information: Control Plane Capability
Flags and Data Plane Capability Flags, but agree that this separation should
appear more clearly in the intro. Will update
[DP] ok
=> 4.1. Description
LSRs in a network may have distinct control plane and data plane Traffic
Engineering capabilities. The TE Node capability Descriptor TLV describes
data and control plane capabilities of an LSR. Such information can be
used for instance for path computation algorithm so as to avoid nodes
that do not support a given TE feature either in the control or data
plane or to trigger procedure to handle these nodes. In some case, this
may also be useful for backward compatibility.
[DP] suggest to detail the backward compatibility aspects ? i guess it is
to provide support of legacy LSRs ?
Definitely, the goal of this information is to ease operations in a mixed
environment made of capable and incapable nodes, wrt several control plane
capabilities. Knowledge of incapable nodes, allows capable nodes either
triggering mechanisms in order to support these nodes, or computing a path
avoiding these nodes
For instance, If P2MP capable nodes are aware of non P2MP capable nodes, then
they can automatically trigger a mechanism allowing support for non P2MP
capable nodes (e.g. trigger a FA-LSP or LSP-segment to the next P2MP capable
node), or they may compute a Tree avoiding these nodes.
[DP] ok and inline with the P2MP developments
=> 4.2. Required Information
The TE Node Capability Descriptor TLV contains two variable length sets
of bit flags: the Control Plane Capability flags and the Data Plane
Capability flags. Each flag corresponds to a given capability. Two flags
are currently defined in the Data Plane Capability Flags:
B bit: when set, this flag indicates that the LSR can act as a branch
node on a P2MP LSP (see [P2MP-REQ]) and [RSVP-P2MP]).
E bit: when set, this flag indicates that the LSR can act as a bud LSR on
a P2MP LSP, i.e. and LSR that is both transit and egress.
[DP] if your point is that a branch LSR could not necessarily be an egress
then for a branch being also an egress both E and B bits should be set ?
Yes, for a branch and egress capable node, both E and B bits should be set.
[DP] ok
the question is related to the atomicity of the bits, i understand the B
bit (it means i can be a branch node in addition to a pre-defined set of
tapabilities assumed by default, in my view this should be spelled out or
pointed from the P2MP docs), in brief: B bit = branch node but doesn't say
capability in terms of ending streams E bit = transit + egress
so probably B bit should also say branch + egress and then E bit would only
appear as particular case of the B bit - do you see any restriction here ?
There may be cases where a node can act as a branch node but cannot act as an
egress (ie cannot end the stream), and we should handle these cases.
Basically we have two distinct capabilities, so we need two bits. (see
section 5.12 of the P2MP requirements ID).
[DP] if we consider branch that can't be egresses shall we then consider that
any node should be by default able to be an egress ?
Three flags are currently defined in the Control Plane Capability Flags:
M bit: when set, this flag indicates that the LSR supports MPLS-TE
signalling ([RSVP-TE]).
G bit: when set this flag indicates that the LSR supports GMPLS
signalling ([RSVP-G]).
P bit: when set, this flag indicates that the LSR supports P2MP MPLS-TE
signalling ([RSVP-P2MP]).
[DP] is the P bit expected to be used only when the M bit is set ?
The P2MP requirement document points out, in backward compatibility section:
"Unless administratively prohibited, P2P TE LSPs MUST be supported through a
P2MP network."
So when the P bit is set the M bit should be set, but there may be particular
cases where the operator wants to dedicate an LSR for P2MP, and in that case
P is set and M is not set.
[DP] ok
also in that case P bit should refer also to GMPLS => "P bit: when set,
this flag indicates that the LSR supports P2MP G/MPLS-TE signalling
([RSVP-P2MP])"
Shouldn't we handle cases where an LSR support [RSVP-P2MP] for MPLS-TE but
not for GMPLS (ie no support of 3473) ?
[DP] but then we would need the counter-part for GMPLS RSVP P2MP, so
basically can we expect nodes having MPLS for P2P & P2MP and GMPLS for P2P only
Note that new flags may be added if required.
[DP] would be probably useful to indicate the criteria to be part of this
TLV
Criteria = Any control plane capability that can be identified by a single
bit. We will add a sentence in next revision
[DP] ok
=> 4.3. Procedure
The TE Node Capability Descriptor TLV is carried in Link State
Advertisements. A router MUST originate a new Link State Advertisement
whenever the content of this information changes, or whenever required by
regular routing procedure (e.g. refresh).
[DP] would you indicate that scaling should be preserved by this
advertisement since 1) it is not expected that it's variation be much
smaller than refresh time ans 2) usage of this information does not trigger
generation (delayed via pacing or not) of a new advertisement)
Agree, thanks, we will add some text on this point
[DP] in the context of this functional document i would suggest to expand on
this since it is one of the turn key to make this approach workable
TE Node Capability Descriptor TLVs are optional. When a Link State
Advertisement does not contain any TE Node capability Descriptor TLV,
this means that the TE Capabilities of that LSR are unknown.
[DP] what would extinction reflect in this context ? it would be
interesting to detail the expected behaviour of extinction (i.e. LSR lost
its capability)
Once an LSR loose a given capability, an updated Link State Advertisement
must be immediately flooded. The way how to handle such extinction (e.g. LSP
rerouting...) is beyond the scope of this draft.
[DP] since this document describes functionality could be advisable to
include the above statement in the text
=> 5.1. Description
The PCE Discovery Information allows for the auto-discovery of one or
more Path Computation Element(s). In various MPLS and GMPLS situations,
such as inter-domain TE or backup path computation, an LSR may require
to send a request to a Path Computation Element (PCE) to compute one or
more TE LSPs paths obeying a set of specified constraints. Note that a
PCE can be an LSR or an offline tool without any forwarding capability.
[DP] instead of mentioning "LSR or an offline tool" it would be better to
refer to co-located or a non-co-located tool because the accessibility is
independent on the location - the point is to avoid mentioning the TE tool
access mode and make it independent from its localisation and distribution
Agree that the term "offline tool" is not appropriate here. What about "A PCE
can be a centralized tool, not forwarding packets, or an LSR"
[DP] ok
=> 5.2. Required Information
[...]
L bit: Local scope. When set, this flag indicates that the PCE can
compute paths for the area/level the PCE Discovery Information TLV is
flooded into (the PCE can compute TE LSP paths for intra-area TE LSPs).
I bit: Inter-area scope. When set, the PCE can perform TE LSP path
computation for inter-area TE LSPs but within the same AS.
A bit: Inter-AS scope. When set, the PCE can perform path computation for
inter-AS TE LSPs.
Note that those flags are not exclusive (a PCE may set one or more flags).
[DP] so imagine an inter-AS LSP for which an expansion (intra-area) has to
be performed normal the L bit should be used however, it doesn't seem to be
possible since restricted to intra-area LSPs so the above classification is
imho performed in terms of "LSP scope" while it should also be provided in
terms of computational scope no matter the type of LSP - so i would suggest
to rework the text here above and decouple computation capability (scope)
from the LSP scope in its description
the issue is that we have "expansions" and "destination" (session end-point)
- expansion of the ERO can be in the present context: intra-area or
multi-area which is coupled to the PCE capability - destination can be in
the same area (intra-area LSP), in a different area i.e. same AS
(multi-area LSP) and in a different AS (multi-AS LSP)
i think this point of discussion should be processed around these lines
(note that there are cases in the matrix that can be built from the above
that are unapplicable or simply irrelevant)
Actually these bits refer to the capability of a PCE to process a request for
an intra/inter area/AS LSP, ie to participate in the computation of an
intra/inter area/AS LSP, whatever the scope of its own computation capability
(ie it can compute it alone, or needs collaboration with other PCEs (ex an
ABR))
Basically when a PCED capability TLV with the I bit set is flooded within an
area, this means that this PCE can handle an inter-area path computation
request, and that all LSR in the area can send an inter-area Path computation
request to this PCE. LSRs don't need to known if this PCE can compute the
path alone (e.g it has knwoledge of the topology of all areas) or if
collaboration with other PCEs is required (e.g. an ABR).
But I Agree that the current definitions do not well reflect that, and have
to be updated.
E.g. for the I bit:
"I bit: Inter-area support. When set, this flag indicates that the PCE can
handle requests for computation of inter-area paths within the same AS (It
can contribute partially or entirely in the computation of an inter-area
path)"
[DP] ok, would be clearer with this update (in addition to the
corresponding revision of the definition for the L bit)
P bit: Request Priority. The notion of request priority allows a PCC to
specify the degree of urgency of a particular request. When set, this
flag indicates that the PCE takes into account the 'request priority' in
its scheduling of the various requests.
[DP] would you clarify here - because if all routers receive this
information all of them can potentially make use of this information so it
is not helping in solving the request scheduling in sequencing of the
request one may face with a PCE
Some request are more urgent than others, for instance backup path
computation requests. Some PCE may be able to prioritize requests and others
no. This flag allows an LSR selecting a PCE that can take into account
request priority among a set of candidate PCEs
Basically a Request priority policy can be configured on each LSR, for
instance: Backup Computation: High priority Intra-area computation: Medium
priority Inter-area computation: Low priority
[DP] ok this clarifies the point - this bit is relevant when used in
combination with request priority policy on PCC's
In case of LSP failure, the head-end will send a request with a high priority
to a PCE that support request prioritization
Some policing may be also used on the PCE in order to avoid any priority
abuse
[DP] this would make sense in order to avoid any priority overload so it
is also expected to be used in combination with policing on PCE's to
ensure that the adertized capability can be met
M bit: Multiple Path Computation. When set, this flag indicates that the
PCE is capable of computing more than one path obeying a set of specified
constraints (in a single pass), provided that they exist.
[DP] so it is a multi-path, multi-constraint computation ?
It means that the LSR can compute a set of constrained path in a coordinated
manner. This bit does not indicate wether or not the PCE can compute paths
with multiple additive constaints (also an NP-Hard problem) like e.g. minimum
cost bounded delay paths. This may require an additional bit.
[DP] ok thanks for the clarification; would it be possible then to
indicate (or something equivalent at your discretion)
"M bit: indicates that the LSR can compute a set of constrained path in a
coordinated manner.
Note: The M bit does not indicate whether or not the PCE can compute a set
of paths with multiple additive constaints (also an NP-Hard problem) like
e.g. minimum cost bounded delay paths. This requires an additional bit."