The MPLS WG Archive

["LE ROUX Jean-Louis FTRD/DAC/LAN" <jeanlouis.leroux@rd.francetelecom.com>]

Title: Comments about draft-vasseur-mpls-computation-rsvp-03.txt

Hi JP and all,

I have several comments regarding draft-vasseur-mpls-computation-rsvp-03.txt

Except several points mentionned below,  requiring several clarifications,
this ID results IMHO a good base for PCC-PCS signaling.
What is the current status of this draft ?
Has there already been a call for moving to WG document ?

Here is a list of points that could require several clarifications:

_____________________________________________________________________

*1*:
End of the Abstract (p 2)
It is mentioned, that Path Computation messages could be used as a UNI protocol between a CE and a PE.
There is no longer other reference to such application in the rest of the draft, so what do you mean by UNI in such VPN context ?

*2*:
3.3.1 page 9: T bit definition

Processing of T bit requires several clarifications:
-If the PCC requests a full path (T bit=1), and the PCS can only compute a partial path, does it send a negative reply ?

-If the PCC requests a partial path (T bit = 0) and the PCS can compute a full path, does it replies only a partial path ?

And in that case which rules are applied for removing hops ? (for instance remove all nodes except ASBR ?)

It should be interesting to illustrate the use of T bit by an example ( inter AS scenario...)

*3*:
3.3.1 page 9, reoptimization,
It is mentioned that
"If the PCC has previously requested a Partial ERO, a reoptimization can still be requested by the PCC, but this implies for the PCS to be statefull (keep a trace of the previously computed path with the associated list of strict hops)".

Comments:
-This assumes that the PCS could compute the full path.
-In case the PCC knows the full path thanks to the RRO, Path state maintaining is not required on the PCS.

*4*:
3.3.4, NO_PATH_AVAILABLE object (p 14 & 15)

It is mentioned: "Note that several NO_PATH_AVAILABLE" objects may be included in the Path Computation Reply message, so that the PCS may indicate the list of constraints for which no path has been found".

But how to distinguish a set of independant blocking constraints from a set of dependant blocking constraints.
-By set of independant blocking constraints, I mean a set of constraints whose relaxation of only one constraint in the set is required to find a path.

-By set of dependant blocking constraints, I mean a set of constraints whose simultaneous relaxation of all constraints in the set is required to find a path.

A path may be found by relaxing only one blocking constraint at a time, or by relaxing simultaneously multiple constraints.

Example :
 PCC requests for a bidirectional path with bandwidth 10M

Request
<SESSION>
<REQUEST-ID>=a,B=1, L=1
sender_tspec: bw=10M

-Case 1, the PCS can only find a unidirectional path with bandwidth 10M or a bidirectional path with bandwidth 9M.
In that case a path can be found by relaxing only one constraint

-Case 2, the PCS can only find a unidirectional path with bw 9M
In that case a path can be found only if two constraints are relaxed

With current spec there is no possibility to distinguish the two replies.
Indeed, in both cases it is:

Reply
<REQUEST-ID>=a, B=1, L=1
<ERROR-SPEC>
<NO-PATH-AVAILABLE> : Flag=0X01, constraint-type= 0x0001, suggested-value= 9m
<NO-PATH-AVAILABLE> : Flag=0X01, constraint-type= 0x0005, suggested-value= unidir

So this object should be modified to take into account constraints dependancy
 
Proposal: The NO_PATH_AVAILABLE object is made of one or more subobjects identifying a set of "dependant" constraints

In that case we have the following replies:

-Case 1:
Reply
<REQUEST-ID>=a, B=1, L=1
<ERROR-SPEC>
<NO-PATH-AVAILABLE> : Flag=0X01,
        Subobject 1: constraint-type= 0x0001, suggested-value= 9m
<NO-PATH-AVAILABLE> : Flag=0X01,
           Subobject 1: constraint-type= 0x0005, suggested value= unidir

-Case 2:
Reply
<REQUEST-ID>=a, B=1, L=1
<ERROR-SPEC>
<NO-PATH-AVAILABLE> : Flag=0X01,
        Subobject 1: constraint-type= 0x0001, suggested value= 9m,
        Subobject 2: constraint-type= 0x0005, suggested_value= unidir
 

*5*:
3.3.4 (p14 & 15): NB-PATH object,  S bit definition

It is mentioned that
 "-S=0: the PCC requests the computation of (potentially correlated) number-path paths that SHARE THE SAME SET OF CONSTRAINTS.

  -S=1: the PCC requests the computation of number-path correlated paths HAVING DIFFERENT SET OF CONSTRAINTS. The set of constraint of each path is defined in a different Path computation request..."

As I understood from the various provided examples :,
-In case of global bandwidth request, S is set to 0 and N is set to 1, because you don't know the number of paths and the bandwidth constraint for each path, but only the global bandwidth.

The answer is a set of paths with potentially distinct bandwidths.
Thus these paths don't share the same set of constraints (distinct bandwidth), and this is not consistent with S=0 definition

For instance see example 1 or 2 in 3.3.8 (p23 & 24):
Path computation of a set of diversely routed paths sharing THE SAME set of constraints. The reply consists of three paths with distinct bandwidths x1, x2 and x3, thus not sharing the SAME set of constraints

 
The expression "share the same set of constraints" must be clarified,
In example 1 and 2 it seems that bandwidth is not part of constraints.

Other comments regarding the case S=0 :

-What are the values of the tunnel id and LSP id, in SESSION and Sender_Template objects in a request for multiple paths sharing the same set of constraints ?

This should be clarified in the draft.

-The utilisation of Sender_TSpec bw value is not clear. Indeed when S=0 and N=0 , It may represent  individual path bandwidth or global bandwidth (case of global bandwidth request).

Ex:

Request 1: 4 paths sharing the same set of constraints, whose global bandwidth is X = Global bandwidth request
Request 2: 4 paths sharing the same set of constraints, whose individual bandwidth (bw for one LSP) is X

With current spec there is no mean to distinguish these two requests.
In both cases the request is:
<SESSION>
<REQUEST-ID>
<NB-PATH>= Flag: N=0, S=0, number-path=4, 
sender_tspec: bw=X

So it should be good to add a flag in order to distinguish request for n potentially correlated path sharing the same set of constraints (including bandwidth) , from a global bandwidth request with a fixed number of paths.(see below, proposed G bit)

*6*: (Similar to 5)
3.3.4 Example 3 (p24 & 25)

Example 3 is not consistent with examples 1 and 2:

Example 1&2: Global bandwidth request,  paths share the same set of constraints (S=0) => result is a set of path with distinct bandwidths.

Thus it seems from these two examples that bandwidth is not taken into consideration when you say "sharing the same set of constaints"

Example 3: Global bandwidth request,  paths not share the same set of constraints (S=1)
Does bandwidth is taken into consideration now when you say  "not sharing the same set of constraints"  ? or do you mention other constraints ?

Further more the Request message is not conform to rules with S=1.
Indeed it is mentioned
        -Page 16: when S=1, "the set of constraints of each path is defined in a DIFFERENT path computation message, identified by the request ID number"

        -Page 18: "If the PCC requests the computation of number-path correlated paths having different set of constraints, the NB-PATH object MUST just be present in the first of number-path requests"

Here in example 3, S=1, but the Path Computation Request message includes two requests  and also one NB-PATH object per request. So it is not conform to S=1 rules.

There are two options to correct points 5 and 6 issues :
        -Option 1: Change S=1 rules to make example 3 (3.3.8) request and reply messages conform, and modify S=0 definition

        -Option 2: Add a third field in NB-PATH flag to explicitely identifiy a global bandwidth request

I suggest the second option, that seems semantically more relevant.
Proposed procedure :
        -Add a third field, G bit, in NB-PATH object flag, in order to distinguish request for a set of  (potentially correlated) paths, sharing or not the     same set of constraints, for which individual LSP bandwidth are known, from a global bandwidth request, for which individual LSP bandwidth are  not known

        -Restrict the use of S=0 to the Request of a set of paths sharing exactly the same      set of constraints, including bandwidth.

G bit rules:
G=0 : Computation of a set of (potenttialy correlated) paths, whose bandwidth is known, sharing or not the same set of constraints (S=0 | S=1)

When G=0, N must also be set to 0

G=1 : for global bandwidth request: Computation of a set of (potentially correlated) paths, whose only global bandwidth (sum) is known.

When G=1, S must also be set to 1 because the set of path do not necessarily have the same bandwidth

Then there are four cases:

1-Global bandwidth request with fixed number of paths:
Computation of exactly N (potentially correlated) paths sharing the same set of constraint except bandwidth, whose global bandwidth is X.

 => G=1, S=1, L=0

2-Global bandwdith request with undetermined or maximal number of path:
Computation of a maximum of N (potentially) correlated) paths sharing the same set of constaint except bandwidth, whose global bandwidth is X.

 => G=1, S=1, L=1
n may be undetermined ie =0xFFFF, in that case it is relevant to specify min_bandwdith

3-Computation of exactly n  (potentially correlated) paths sharing the same set of constrains, including bandwidth, whose individual bandwidth is X.

=>G=0, S=0, L=0

4-Computation of exactly N correlated paths not sharing the same set of constraints.
=>G=0,S=1, L=1

To my mind this would simplify Path Computation Request processing on the PCS.

Examples

1: Computation of 4 diversly routed paths, sharing same set of constraints, except bandwidth, whose global bandwidth is 10m

Request
<SESSION>
<REQUEST-ID>= a
<NB-PATH>= Flag: G=1, S=1, N=0, number-path=4, path-correlation=0x02
sender_tspec: bw=10m

2: Computation of a maximum of 4 diversly routed paths, sharing the same set of constraints, except bandwidth, whose global bandwidth is 10m , and minimum lsp bandwidth 2m:

Request
<SESSION>
<REQUEST-ID>= a
<NB-PATH>= Flag: G=1, S=1, N=1, number-path=4, path-correalation=0x02
sender_tspec: bw=10m
<MIN-BW>: minimum-bw=2m

3: Computation of 4 diversly routed paths sharing the same set of constraints (including bandwidth) with individual bandwidth 10m

Request
<SESSION>
<REQUEST-ID>= a
<NB-PATH>= Flag: G=0, S=0, N=0, number-path=4, path-correlation=0x02
sender_tspec: bw=10m

4: Computation of 2 diversly routed paths not sharing the same set of constraints (bw 1 = 10M, bw 2=5M)
Request 1
<SESSION>
<REQUEST-ID>= a
<NB-PATH>= Flag: G=0, S=1, N=0, number-path=4, path-correlation=0x02
sender_tspec: bw=10m
<PATH_CORRELATED>= a, b

Request 2
<REQUEST-ID>= b
sender_tspec: bw=5m

________________________________________________________________