[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RE : draft-vasseur-ccamp-te-router-info-00
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."
D bit: Diversity. When set, this flag indicates that the PCE is capable
of computing diversely routed paths (link, node, SRLG). The PCC may
request the PCE to compute N diversely routed paths obeying a set of
specified constraints. Such N paths may not exist of course depending on
the current state of the network.
[DP] is that not a particular case of the previous bit ?
Yes it is, if D is set M must also be set.
[DP] ok, useful to indicate this specific case
If the PCE is capable of computing inter-AS TE LSP path, the PCE
Discovery Information TLV MAY also contain the list of AS numbers
identifying the AS for which the PCE can compute inter-AS TE LSP paths
(TE-LSPs having their destination address in this AS). This set is
optional and should be included only when the A bit is set.
[DP] did you evaluate the potential length of such advertisement ? and the
"loop" created with BGP information ? since the text says "MAY also contain
the list of AS numbers identifying the AS for which the PCE can compute
inter-AS TE LSP paths" so each time new AS's will be known this list will
potentially be updated, drawing some lines along this point will help here;
In practice an inter-AS TE "domain", will contained a limited number of
ASes. Also, in case a PCE can compute an inter-AS Path for any destination
AS, then destination ASes are not included.
Further more the objective of this information is to allow balcaning path
computation load among a set of PCEs in a given AS, based on destination
ASes. For instance, an AS could contain 5 PCEs, each one being responsible
for the computation of inter-AS LSPs to 20 destination ASes. This would allow
supporting an inter-AS TE "domain" comprising 100 ASes, with only 20 ASes
listed per PCE.
We will add some text on this point
[DP] ok, this text will be useful - also, when you mention "inter-AS TE domain"
do you mean a multi-AS single carrier environment ? or do you refer to something
else ?
another aspect is to distinguish between multi-AS single carrier and
multi-AS multi-carrier, and restrict the latter to stringent policy rules
in terms of AS path considered for LSP
Yes, but again the goal of this information is more a way to allow an LSR
selecting the appropriate PCE among a set of candidate PCE, when the
computation load is balanced based on the destination AS. Policy rules for
AS-path selection are beyond the scope of this ID, and should be addressed in
separate drafts
[DP] i understand that policy for AS path selection is beyond the scope of this
document but the relevance of including this information as part of the IGP
flooded information should be also clarified at some point in time
=> 5.3. Procedure
The PCE Discovery Information 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)
The PCE Discovery Information TLV is optional.
If the PCE can compute an intra-area TE LSP path, the L bit MUST be
set.If it can compute an intra-area TE LSP path only for the LSRs in the
area it resides in, then the PCE Discovery Information must be contained
within an area. Otherwise, if the PCE can compute intra-area TE LSP
paths for the whole AS, then the PCE Discovery Information TLV must be
flooded across the whole AS.
[DP] how do you ensure that LSR's not being part of this area can reach the
PCE (i.e. is there not a reachability constraint to be added here ? in
particular in case of non-co-located PCE identified by an IP address) - i
guess this point should be somehow clarified
A PCE, supporting this draft, either LSR or centralized, will run the IGP.
Thus it will be reacheable. We will clarify this point.
[DP] but then you have to ensure that no IP data traffic could reach the
centralized PCE (since by definition it will be only capable to process IP
control messages request/response, etc.) ie one has to exluce IP data traffic
from the corresponding IP control channels
If the PCE can compute an inter-area TE LSP path, the I bit MUST be set.
If it can compute an inter-area TE LSP path only for the LSRs in the
area(s) it resides in (for instance the PCE is an ABR computing an
inter-area TE LSP path for its area), then the PCE Discovery Information
must be contained within this or these area(s). Else, if it can compute
an inter-area TE LSP path for the whole AS, then the PCE Discovery
Information must be flooded across the whole AS. If the PCE can compute
an inter-AS TE LSP path, the A bit MUST be set, and the PCE Discovery
Information must be flooded across the whole AS.
[DP] probably it would be then be preferable to refer an "external AS" path
since the PCE is able to perform three expansions: intra-area, inter-area
(single AS) and inter-AS (where AS in the latter refers to "external AS"
from the one of the path computation requestor)- see also above comment
concerning expansion vs session
See above answser
[DP] ok
[...] => 6.2. Required Information
The TE Mesh Group Information TLV allows an LSR to advertise the set of
TE mesh-groups it belongs to. For each mesh group announced by the LSR,
the TE Mesh Group Information TLV carries the following set of
information:
-A Mesh-Group number identifying the TE mesh-group, -A Tail-end address
(address used as a tail end address by other LSRs belonging to the same
mesh-group),
[DP] is this not part of the advertising router information, or you are
looking for an additional auxiliary information here to be used a Tunnel
end point address ?
This is basically a 32 bit id used to identify a mesh-group
my concern is that there should be a statement then saying the Mesh group
ID must 1) be taken from a flat 32 bit id space 2) non routable information
3) unicity on a per AS basis and 4) there is no containment relationship
wrt to the tail-end address space
Agree, will add such statement
[DP] ok
-A Tail-end name: string used to ease the TE-LSP naming (e.g.
'head-name->tail-name').
[DP] is this to be used as part of the Session name field of the SESSION
ATTRIBUTE object or the Extended Tunnel ID ?
Yes
[DP] thanks for the clarification
=> 6.3. Procedure
[DP] here i am concerned with an operational aspect what happens when this
information is not refreshed do the LSP have to be torn down, stay
unaffected ?
They have to be torn down
[DP] ok that it is expected to (potentially) trigger a subsequent signaling
operation
since as stated above "The TE Mesh-Group Information allows an LSR to
advertise its desire to join/leave one or more TE mesh-groups."
[DP] also a rule could be defined something like "A given TE Mesh Group ID
information is to be considered by a node X for setting up n LSPs from this
node X to a set of destination LSRs n if this TE mesh group ID value has
been advertised by that node X and received from a set of n nodes (n =< N)
being part of that set" in order to clarify these procedures
This is already implicitely mentionned in section 6.1 But actually such rules
are related to TE mesh group processing and not to IGP processing, and are
thus beyond the scope of this draft. Maybe we need to detail a little bit
more these TE-mesh group procedures, in the description section, in order to
allow for better understanding of the uses of this info.
[DP] i agree it falls at the boundary on the other hand as there are no specific
document for TE mesh groups this
Again thanks a lot for these highly relevant comments,
thanks,
- dimitri.
JL