Re: draft-vasseur-ccamp-te-router-info-00

[Dimitri.Papadimitriou@alcatel.be]

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

=> 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 ?

=> 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 ?
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 ?

>  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 ? 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])"

>  Note that new flags may be added if required.

[DP] would be probably useful to indicate the criteria to be part of this
TLV

=> 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)

>  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)

=> 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

=> 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)

>  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

>  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 ?

>  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 ?

>  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;
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

=>  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

>  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

[...]
=> 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 ? 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

>  -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 ?

=>  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 ? 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