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

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Sun, 25 Jul 2004 13:29:17 +0200

Hi Dimitri and all,

Thanks a lot for these really useful comments
Please see inline

>-----Message d'origine-----
>De : [email-masked] 
>[mailto:[email-masked]] 
>Envoyé : jeudi 22 juillet 2004 20:43
>À : Adrian Farrel
>Cc : [email-masked]; '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

---

From: dimitri papadimitriou <[email-masked]>
Date: Sun, 25 Jul 2004 19:13:23 +0200

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 : [email-masked] 
>> [mailto:[email-masked]] Envoyé : jeudi 22 juillet 2004
>> 20:43 À : Adrian Farrel Cc : [email-masked]; 'Jean Philippe Vasseur';
>> LE ROUX Jean-Louis RD-CORE-LAN Objet : Re:
>> draft-vasseur-ccamp-te-router-info-00
>> 
>> hi adrian, all,
>> 
>>> 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
>>> 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

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

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

[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

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

>>> Advertisements. A router MUST originate a new Link State Advertisement
>>> whenever the content of this information changes, or whenever required by
>> [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)
> 

[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

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

>>> 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).
>>> 
>>> A bit: Inter-AS scope. When set, the PCE can perform path computation for
>>> inter-AS TE LSPs.
>>> 
>> [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
>> 
>> - 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).
> 
> "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
> 

[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
> 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] ok, useful to indicate this specific case

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

[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

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

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

[DP] ok

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

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

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Tue, 27 Jul 2004 20:11:28 -0400

Hi Dimitri,

Thanks for your comments - see in line.

At 07:13 PM 7/25/2004 +0200, dimitri papadimitriou wrote:
>[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
>
>[DP] since this document describes functionality could be advisable to 
>include the above statement in the text
>
>>>=> 5.1. Description
>>>
>>>>Note that those flags are not exclusive (a PCE may set one or more flags).
>>>the issue is that we have "expansions" and "destination" (session end-point)
>[DP] ok, would be clearer with this update (in addition to the 
>corresponding revision of the definition for the L bit)
>
>[DP] ok this clarifies the point - this bit is relevant when used in 
>combination with request priority policy on PCC's
>
>[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
>
>[DP] ok thanks for the clarification; would it be possible then to 
>indicate (or something equivalent at your discretion)
>
>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."

The aim of the M bit is just to mention that the PCE has the ability to 
compute a set of M paths, considering that those paths may have different 
constraints *and* could be related (ex: compute a set of N link diverse paths).

>[DP] ok, useful to indicate this specific case

ok

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

May be multiple AS of the same SP or multiple AS of different SP.

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

but outside of the scope of the IGP flooding.

>control messages request/response, etc.) ie one has to exluce IP data 
>traffic from the corresponding IP control channels

Well, no, it is the choice of the operator to choose a PCE dedicated for 
path computation or to activate the PCE function on an LSR forwarding packets.

>>>>the TE Mesh Group Information TLV carries the following set of information:
>>>

note that the head-end may or not decide to signal it in the SESSION ATTRIBUTE.

>[DP] ok that it is expected to (potentially) trigger a subsequent 
>signaling operation
>
>[DP] i agree it falls at the boundary on the other hand as there are no 
>specific document for TE mesh groups this
>

Thanks for your comments.

JP.

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 29 Jul 2004 19:00:17 +0200

hi jp, see in-line (i have shorten the size of the mail)

[snip]

>> "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."
>  
> compute a set of M paths, considering that those paths may have 
> different constraints *and* could be related (ex: compute a set of N 
> link diverse paths).

[DP] the interpretation i made from jean-louis response, the draft and 
yours is different, at the end the point is to achieve a unique 
interpretation

>>>>> depending on

[DP] thanks

>>>> will potentially be updated, drawing some lines along this point 
>>>> will help here;
>>>
>> [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 ?
> 

[DP] thanks to clarify in the text

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

[DP] well i'd like to make a point clearer in this context it is not 
because a specific capability is not related to the flooding mechanism 
but only to the carried information that the rationales for carrying 
this information shouldn't be provided with a non ambiguous semantic

in addition it is not because policying of information is outside the 
scope of this document that any information should be part of this 
document without any discussion

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

[DP] i was discussing the non co-located case which does not get 
clarified by your response is there a redirection provided and the LSR 
acts as a proxy (or is it not within the scope of this document ?)

[snip]

[DP] ok

thanks,
- dimitri.

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Fri, 30 Jul 2004 01:17:33 -0400

Hi Dimitri,

At 07:00 PM 7/29/2004 +0200, dimitri papadimitriou wrote:
>>>"M bit: indicates that the LSR can compute a set of constrained path in 
>>>a coordinated manner.
>>>
>>>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."
>>
>yours is different, at the end the point is to achieve a unique interpretation

we will clarify, adding a few words in the next revision, no pb.

>>>[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
>because a specific capability is not related to the flooding mechanism but 
>only to the carried information that the rationales for carrying this 
>information shouldn't be provided with a non ambiguous semantic
>

well .. .not sure of what you would want to see added there ... Again, AS 
path selection is out of the scope and not related to IGP flooding which is 
what this draft is about.

>>>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 
>[DP] i was discussing the non co-located case which does not get clarified 
>by your response is there a redirection provided and the LSR acts as a 
>proxy (or is it not within the scope of this document ?)

is your question to know how one can ensure in this case the PCE will not 
receive any data traffic ?

thanks.

JP.