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

[Dimitri.Papadimitriou@alcatel.be]

hi jp, see in-line starting with [DP]

>[snip]
>
>>>>>> 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."
>>
>> 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] 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

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

[DP] ok - even if i'm not sure one can clarify this with a few words but
let us see first what it gives

[snip]

>>>>> 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 but outside of the scope of the IGP
>>> flooding.
>
> [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

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.

[DP] that there is an assumption that there is already a distinction
between
PCEs in terms of destination AS computation capabilities, while i still do
not see what it brings in terms of load balancing wrt to the case the AS
path
list wouldn't be advertized and assumption is made that those PCEs have the
same information (i don't say capability) within a single AS - the
discussion
shift to a policy issue of using the information i'm still questioning
about
the relevance and consequence of advertizing it (no assessment provided in
the document)

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

[DP] yes, that's part of the problem raised

[snip]

thanks,
- dimitri.