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

["LE ROUX Jean-Louis RD-CORE-LAN" <jeanlouis.leroux@francetelecom.com>]

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 


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


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

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



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

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


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

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

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


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

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



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

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

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


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

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


>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




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

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

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


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

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

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


Again thanks a lot for these highly relevant comments,

JL