Subject: RE: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Mon, 26 Jun 2006 09:03:27 +0200

Hi Dimitri,

[dp] i read this, mind you, my point is that this is not a "constraint" of the same nature as the one you're making use such as minimize delays or whatsover - this constraint is introduced from the computation technique and mechanism of this proposed method  

No, this is not introduced from the path computation technique. 
The AS-path is a constraint of the same nature as link/node inclusion, this is actually a set of abstract nodes to be included. 

By the way "minimze the delay" is NOT a constraint, this is an objective to achieve...

Thanks,

JL

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] 
> Envoyé : lundi 26 juin 2006 08:51
> À : JP Vasseur
> Cc : [email-masked]; [email-masked]; 
> [email-masked]
> Objet : Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt
> 
> hi j-p - see in-line
> 
> 
> 
> 
> JP Vasseur <[email-masked]>
> 26/06/2006 02:42
>  
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     [email-masked], [email-masked], 
> [email-masked]
>         Subject:        Re: [Pce] Re: Comments on 
> draft-vasseur-pce-brpc-00.txt
> 
> 
> hi dimitri,
> 
> On Jun 25, 2006, at 7:35 PM, [email-masked] wrote:
> 
> hi j-p - see in-line
> 
> 
> 
> 
> JP Vasseur <[email-masked]>
> 26/06/2006 01:14
> 
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     "Adrian Farrel" <[email-masked]>, 
> [email-masked], [email-masked], [email-masked]
>         Subject:        Re: [Pce] Re: Comments on 
> draft-vasseur-pce-brpc-00.txt
> 
> 
> hi dimitiri,
> 
> On Jun 25, 2006, at 2:08 PM, [email-masked] wrote:
> 
> the following comment was also discussed during last meeting
> 
> "==
> Section 5.1
> I like the simplicity of section 5.1, but I think you need to 
> point out that if the sequence of domains is known a priori 
> (can you determine it a
> priori?) then the path computed might not be 'optimal' in the 
> usual sense of the word, but that this is OK because the 
> ordered list of domains constitutes an additional constraint 
> on the computation so the resultant path *is* optimal within 
> the constraints applied.
> 
> Can't agree more. Good suggestion, thanks.
> 
> Updated text: "The PCE-based BRPC procedure applies to the 
> computation of an optimal constrained inter-domain TE LSP. 
> The sequence of domains to be traversed can either be 
> determined a priori or during the path computation procedure. 
> The BRPC procedure guarantees to compute the optimal path 
> across a specific set of traversed domains (which constitutes 
> an additional constraint). In the case of an arbitrary set of 
> meshed domains, the BRPC procedure can be used to compute the 
> optimal path across each domain set in order to get to 
> optimal constrained path between the source and the 
> destination of the TE LSP."
> 
> => in brief, how to determine the sequence through which path 
> computation has to be performed because if this sequence was 
> known there is no need for such procedure (only inter-domain 
> link selection would be
> required) -
> 
> Not correct; even if you know the sequence you still need the 
> BRPC procedure to figure out the set of BN (boundary Nodes) 
> to traverse to get the shortest inter-domain TE LSP: this is 
> the whole issue with inter-domain, otherwise per-domain path 
> computation would be sufficient.
> 
> [dp] inter-domain link selection (as i mentioned) implies 
> what you mean with boundary nodes selection - you could 
> rephrase by access/exit point selection exact same business
> 
> but again even if you know the sequence you still need BRPC 
> to determine the set of BN (or exit point - same thing) that 
> will give you the shortest inter-domain path. Look you wrote 
> "in brief, how to determine the sequence through which path 
> computation has to be performed because if this sequence was 
> known there is no need for such procedure", which is not 
> correct. Even if you know the sequence of domains, you still 
> need the procedure to get the exit/entry point (named BN) 
> that provide you the shortest inter-domain path.
> 
> 
> now adrian mentions that pre- determination becomes a new 
> constraint - well actually this is not a constraint for the 
> TE LSP itself but a restriction on the domain set known to be 
> (a-priori) supportive of the method such as to make the 
> method not returning an error message
> 
> 
> No, this is a constraint: "Give me the shortest path 
> (potentially made of loose hops (the BNs)) that provides the 
> shortest end to end path, considering that the additional 
> constraint is to traverse the following set of domains <D1, D2, ....>.
> 
> [dp] incorrect, this is not a "TE LSP" constraint - 
> 
> Who said that this was a TE LSP constraint ? This is *a* 
> constraint. If you impose the set of domain, this is a constraint.
> 
> Please read the text: "The BRPC procedure guarantees to 
> compute the optimal path across a specific set of traversed 
> domains (which constitutes an additional constraint)."
> 
> [dp] i read this, mind you, my point is that this is not a 
> "constraint" of the same nature as the one you're making use 
> such as minimize delays or whatsover - this constraint is 
> introduced from the computation technique and mechanism of 
> this proposed method 
> 
> Note that at this point, I still do not see the point that 
> you're trying to make here ?
> 
> since so far when
> a set of domains do not support/or support a given 
> computation has not yet become a constraint
> 
> hence sentence "The BRPC procedure guarantees to compute the 
> optimal path across a specific set of traversed domains 
> (which constitutes an additional constraint). In the case of 
> an arbitrary set of meshed domains, the BRPC procedure can be 
> used to compute the optimal path across each domain set in 
> order to get to optimal constrained path between the source 
> and the destination of the TE LSP."
> 
> should as far as i understand the method fulfill the following
> 
> a) this method provides a result iff all domains traversed by 
> the request support the proposed method
> 
> BRPC is a multi-PCE based approach where you need at least 
> one PCE per-domain.
> 
> [dp] indeed, but one PCE supporting that method and having 
> FULL visibility of the domain
> 
> So what is your point here ?
> 
> [dp] that the set of conditions to have this method workable 
> is larger than the one listed in this doc.
> 
> b) this method provides an "optimal" result iff
> 
> b1) all possible sequences of domains have been traversed 
> (starting from the root) and are supportive of that method - 
> as there might be an optimal path through a domain not 
> supporting this method -
> 
> 
> heu ... yes indeed. If a domain does not support the method, 
> the method cannot be used to compute the path.
> 
> b2) there is no discontinuity in the availability of the 
> inter-AS link information on each PCE performing a given 
> selection - indeed a domain might be supportive of the method 
> without supporting inter-AS link flooding
> 
> No this is not a requirement, just an optimization. The only 
> requirement is for the PCE to get the TE-related data about 
> the Inter- AS links. I'll detail a bit more in the next revision.
> 
> [dp] then you can never achieve -
> 
> You can never achieve what ?
> 
> Sorry Dimitri, I'd love to accommodate your comment but I do 
> not see your point ... hopefully we'll have a bit of time in 
> Montreal to discuss if that does not work by email.
> 
> [dp] my point is that without this additional information you 
> can not achieve the expected result - i pointed to your own 
> text to indicate that this information is a must have in 
> order to achieve this objective 
> 
> using your own words to make it more
> straighforward - 
> 
> "you still need the BRPC procedure to figure out the set of 
> BN (boundary
> Nodes) to traverse to get the shortest inter-domain TE LSP: 
> this is the whole issue with inter-domain, otherwise 
> per-domain path computation would 
> 
> be sufficient."
> 
> b3) at each step there is no PCE that has partial visibility 
> of a given domain
> 
> 
> This is not specific to BRPC. Even with intra-domain if you want to 
> compute the path for a TE LSP, you cannot always use the PCE if it 
> has a partial visibility. Note that this also applies to the case of 
> co-located PCE (when the path is computed by the head-end).
> 
> [dp] hence, to BRPC as well
> 
> b4) during the selection process no network conditions changes 
> (that would
> make the returned result void)
> 
> 
> Again, this applies to other cases as well.
> 
> [dp] ditto
> 
> 
> Ah so we agree here :-)
> 
> What was your comment then ?
> 
> [dp] that you need to include these set of working conditions in the 
> document itself, the document looks like quite simple in terms of 
> conditions for having the proposed method working as expected 
> while when 
> you take a closer look at it this is not the case
> 
> Thanks.
> 
> JP.
> 
> 
> 
> thanks.
> 
> JP.
> 
> 
> 
> 
> 
> 
> JP Vasseur <[email-masked]>
> 23/06/2006 16:11
> 
>         To:     "Adrian Farrel" <[email-masked]>
>         cc:     [email-masked], [email-masked],
> [email-masked]
>         Subject:        [Pce] Re: Comments on
> draft-vasseur-pce-brpc-00.txt
> 
> 
> Many Thanks Adrian for the comments.
> 
> We incorporated the vast majority of them in the new revision (just
> posted).
> 
> See below for the comments requesting some clarification.
> 
> On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote:
> 
> Hi,
> 
> Thanks for keeping these ideas alive.
> 
> Here are some picky thoughts that you may want to include in the next
> revision to make it more robust as a document. I don't have any issues
> with
> the basic process.
> 
> Thanks,
> Adrian
> 
> ==
> Is this I-D likely to be Informational or Standards Track? From 
> Appendix
> A,
> this looks like Standards Track. Can you remove Appendix A and put the
> status in the usual place in the header?
> ==
> 
> Status has been updated (Informational) but let's discuss this 
> later on.
> FYI, it does not appear on the front page when using the xml2rfc 
> editor
> (which by the way is excellent), thus the appendix addition.
> 
> It would be nice if the Abstract contained a pithy summary of brpc 
> and/or
> gave the motivation for the draft. For example, what is the method 
> trying
> to
> achieve that isn't achievable by other methods? Or, what is the
> fundamental
> element of brpc that is not in other methods?
> 
> Agree. Here is the new Abstract:
> "The ability to compute constrained shortest Traffic Engineering (TE)
> Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) 
> and
> Generalized MPLS (GMPLS) networks across multiple domains (where a 
> domain
> is referred to as a collection of network elements within a common 
> sphere
> of address management or path computational responsibility such as IGP
> areas and Autonomous Systems) has been identified as a key 
> requirement .
> This document specifies a procedure relying on the use of multiple 
> Path
> Computation Elements (PCEs) in order to compute such inter-domain 
> shortest
> constraint paths, using a backward recursive path computation 
> technique
> while fully preserving confidentiality requirements across domains. "
> 
> 
> ==
> I'm assuming that section 1 is for short term information only and 
> will be
> deleted (in the next revision?)
> ==
> 
> Indeed, just to provide a bit of history for the ones who have been
> following inter-domain path computation for a while.
> 
> ==
> Section 4
>   - No topology or resource information is distributed between domains
>   (as mandated per [RFC4105] and [RFC4216]), which is critical to
>   preserve IGP/BGP scalability and confidentiality in the case of TE
>   LSPs spanning multiple domains.
> You should clarify what you are saying here, because many would 
> argue that
> reachability information (i.e. external routes) constitutes 
> topology and
> resource information.
> 
> 
> OK fine
> 
> ==
> Section 4
>   - While certain constraints like bandwidth can be used across
>   different domains, certain other TE constraints like resource
>   affinity, color, metric, etc. as listed in [RFC2702] could be
>   translated at domain boundaries.  If required, it is assumed 
> that, at
>   the domain boundary LSRs, there will exist some sort of local 
> mapping
>   based on offline policy agreement, in order to translate such
>   constraints across domain boundaries during the inter-PCE
>   communication process.
> Why does the policy agreement need to be offline?
> 
> 
> It should actually read "pre-determined". Actually the best thing 
> to do
> here is to remove "off-line"
> 
> ==
> Section 5
>   No assumption is made on the actual path computation algorithm in 
> use
>   by the PCE (it can be any variant of CSPF, algorithm based on 
> linear-
>   programming to solve multi-constraints optimization problems and so
>   on).
> Suggest that you delete the text in parenthesis because it is making
> suggestions that border on assumptions!
> 
> Well I'd suggest to keep it as is since the point is to 
> differentiate the
> path computation procedure from the algorithm to compute each intra- 
> domain
> path segment. Furthermore, we'd like to highlight the fact that the 
> BRPC
> procedure does not mandate for each PCE to use CSPF, could be other
> algorithm.
> 
> ==
> Section 5.1 and throughout
> "BRPC path computation" seems to be tautologous
> 
> It is actually a double tautology ;-) (fixed).
> 
> ==
> Section 5.1
> I like the simplicity of section 5.1, but I think you need to point 
> out
> that
> if the sequence of domains is known a priori (can you determine it a
> priori?) then the path computed might not be 'optimal' in the usual 
> sense
> of
> the word, but that this is OK because the ordered list of domains
> constitutes an additional constraint on the computation so the 
> resultant
> path *is* optimal within the constraints applied.
> 
> Can't agree more. Good suggestion, thanks.
> 
> Updated text: "The PCE-based BRPC procedure applies to the 
> computation of
> an optimal constrained inter-domain TE LSP. The sequence of domains 
> to be
> traversed can either be determined a priori or during the path 
> computation
> procedure. The BRPC procedure guarantees to compute the optimal path
> across a specific set of traversed domains (which constitutes
> an additional constraint). In the case of an arbitrary set of meshed
> domains, the BRPC procedure can be used to compute the optimal path 
> across
> each domain set in order to get to optimal constrained path between 
> the
> source and the destination of the TE LSP."
> 
> ==
> Section 5.2
> The introduction of the term Virtual Shortest Path Tree is hard to 
> parse
> and
> to my mind the definition is arse about tit. I think you could 
> usefully
> add
> some textual definition of what the VSPT is trying to achieve, before
> presenting it in pictorial or abstract form.
> Even more important (I think) is the fact that the tree as presented
> "represents the shortest path between the destination and BR-en 
> (j,i)..."
> Frankly, we are building directional paths in exactly the oposite
> direction!
> 
> This is an abstract form of representation but see below,
> 
> So the VSPT is still a tree, but it is an MP2P tree, not a P2MP 
> tree as
> described.
> I suspect that this is just a textual descriptive issue rather than
> anything
> broken in the process.
> 
> 
> I clarified the text to avoid any ambiguity (VSPT defined as a MP2P 
> tree).
> 
> ==
> Section 5.2
> I suggest that you pull the note (Note: in term of computation...) out
> into
> a separate section. It doesn't belong in the middle of section 5.2.
> You will probably want to re-write the text as well since the
> unidirectional
> limit is not necessary. Also to explain 'flood' - flood to where, 
> and how,
> and by whom? And you will want to add to pieces of information:
> - the link to the I-D that defines how to do this
> - a description of what happens if this process is not used.
> 
> This only works for unidirectional LSPs: indeed, the exit boundary 
> node
> can flood TE-related data in its LSA/LSP for the link
> exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP 
> running on
> the link but how would a node in domain (i) get the TE-related data 
> for
> the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction on
> unidirectional link. Are we in sync ?
> 
> ==
> Section 5.2
> The paragraph that begins "BRPC guarantees to find the optimal..." 
> is a
> nascent Applicability Statement. I suggest moving this to another 
> Section
> and significantly beefing it up. You need to describe more fully:
> - how ECMP works (the PCC has to request the return of more than 
> one path)
> - how diversity works (i.e. section 9 fits in here)
> - how some freedom of selection of domains can be offered
> - how to mix the method with other mechanisms
> 
> This was (and is) planned for future revision. Note that ECMP and
> diversity are discussed already but we're planning the flesh out these
> sections in further revision.
> 
> ==
> Section 7
>   If the BRPC procedure cannot be completed because a PCE along the
>   domain path does not support the procedure, a PCErr message is
>   returned by the upstream PCE with a Error-Type "BRPC procedure
>   completion failure".  The PCErr message MUST be relayed to the
>   requesting PCC.
> Not clear to me whether PCE(n) is supposed to know that PCE(n+1) 
> does not
> support brpc, presumably through capabilities
> configuration/advertisement/negotiation, or whether PCE(n+1) is 
> supposed
> to
> respond to the path computation request saying that it does not 
> support
> bit-V of the RP object. If the latter, presumably the PCErr comes from
> PCE(n+1) and not from PCE(n) as documented.
> 
> Good catch, typo: it should read "a PCErr message is returned to the
> upstream".
> The plan is to define a capability bit (IGP) in a further revision.
> 
> ==
> Section 8
> Metric normalisation is a great potential solution, but how does it 
> fit
> with
> AS topology confidentiality? What is the solution to providing 
> discretion
> about what TE connectivity is available within an AS, and operating 
> brpc?
> 
> Metric normalization is handled locally by the PCE and does not 
> impact the
> BRPC procedure per-say. As far as confidentiality is concerned, 
> this only
> requires for the SPs to exchange metric mapping information (nothing
> related to the network topology or resources); for example
> SP 1 Links Cost = F (link_bandwidth) with F (OC192)=1
> SP 2 Links Cost = F (link_bandwidth) with F (OC192)=10
> 
> A simple metric normalization can then be performed on the PCE 
> thanks to
> simple cost mapping tables.
> 
> Section 10
> Some of this text has been seen before in this I-D
> Why do you single out LSP stitching as possibly breaking end-to-end
> optimality. There is functionally no difference between stitching and
> nesting in this respect.
> But further, your statement about stitching is pejorative! If you 
> say that
> "In the case where a domain has more than one BR-en or more than one
> BR-ex,
> optimality after some network change within the domain can only be
> guaranteed by re-executing the full brpc computation" then I would 
> agree
> with you. But as phrased, it implies that making a per-domain
> re-optimisation could make the path *less* optimal. This (of 
> course) is
> not
> the case - per-domain optimisation will always improve or leave the 
> same
> end-to-end optimality (in the case where new resources are made 
> available
> this is obvious; in the case of a network failure, *any* path is 
> better
> than
> no path!)
> And, lastly, the text about re-optimisation belongs in the next 
> section,
> not
> in this section.
> 
> 
> Yes I wanted to leave that text to keep track of who would read the 
> ID,
> expecting reaction ;-)) Per-domain reoptimization would always 
> improve the
> current path *but* in case of stitched LSPs, TE LSP segments are 
> computed
> by the stitching point; thus in case of failure, they could end up
> following a non optimal path whereas in the case of contiguous LSP, 
> the
> BRPC procedure would be called again thus leading to the optimal path
> again. The point that I was trying to make is "if you have a 
> stitched LSP
> and rely on BRPC when first signaled in an attempt to get an 
> optimal path,
> you need to consider the interaction between the local reopt mode 
> and BRPC
> if the goal is to preserve an optimal path at any given time". Anyway,
> we're on the same page and I agree and the text should be reworded
> according to your proposal to avoid any misunderstanding.
> 
> ==
> Section 13
> I would like you to discuss the issues of confidentiality of topology
> information at greater length. It seems that you would possibly use 
> this
> technique in conjunction with path cookies, which is fine. But, are 
> there
> two things you cannot escape from?
> - indicating which BR-en provides best connectivity
> - indicating the metric for multiple BR-ens
> Maybe there are some things that can be done here based on policy,
> including
> not reporting all of the BR-ens, ranking rather than giving absolute
> metrics, etc. But these would compromise optimality.
> 
> Indeed.
> 
> Maybe the PCE(n+1) should carefully monitor and limit 
> (statistically and
> by
> policy) brpc requests so that excessive information is not divulged?
> 
> Since one of objectives for using the BRPC procedure is to compute an
> optimal path, we need to know at least the BN (Boundary Nodes) and the
> cost.
> 
> ==
> I wouldn't mind seeing a Management Considerations section.
> Do we need to be able to examine the pruned pieces of VSPT at transit
> PCEs?
> What are the implications of reporting multiple VSPT branches in 
> PCEP to
> the
> MIB modules?
> Is brpc support something that needs to be configured: per PCE?; per
> PCE-neighbor?
> What are the implications on existing protocols (IGPs? PCEP?) of using
> brpc?
> 
> Absolutely ! I put a placeholder for a further revision.
> 
> Fully supportive of adding such section.
> 
> Many Thanks for your comments !
> 
> JP.
> 
> etc.
> ==
> 
> 
> 
> 
> 
> I think Jean-Louis' email address needs updating
> 
> 
> ==
> The document would benefit from a little care in the formatting, 
> and you
> could usefully re-read it for missing words, etc.
> ==
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pce
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pce
> 
> 
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pce
> 

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: [email-masked]
Date: Mon, 26 Jun 2006 09:19:26 +0200

hi j-l 

"LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
26/06/2006 09:03
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "JP Vasseur" 
<[email-masked]>
        cc:     [email-masked], [email-masked], 
[email-masked]
        Subject:        RE: [Pce] Re: Comments on 
draft-vasseur-pce-brpc-00.txt

Hi Dimitri,

[dp] i read this, mind you, my point is that this is not a "constraint" of 
the same nature as the one you're making use such as minimize delays or 
whatsover - this constraint is introduced from the computation technique 
and mechanism of this proposed method 

No, this is not introduced from the path computation technique. 
The AS-path is a constraint of the same nature as link/node inclusion, 
this is actually a set of abstract nodes to be included. 

[dp] but not for the same reason - isn't it ? -

By the way "minimze the delay" is NOT a constraint, this is an objective 
to achieve...

[dp] i meant "maximum/minimize delay" 

Thanks,

JL