[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

[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

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.

[DP] ok, useful to indicate this specific case

ok 

[DP] thanks

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

[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] thanks to clarify in the text

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

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

[snip]

-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

[DP] thanks for the clarification

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

[DP] ok

thanks,
- dimitri.