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

From: [email-masked]
Date: Mon, 26 Jun 2006 09:20:45 +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" read "maximum/minimum delay" 
(decidemment ;-) 

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

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

---

From: "Gray, Eric" <[email-masked]>
Date: Mon, 26 Jun 2006 09:46:19 -0400

I do. 

--> -----Original Message-----
--> From: Adrian Farrel [mailto:[email-masked]] 
--> Sent: Monday, June 26, 2006 9:14 AM
--> To: [email-masked]
--> Cc: [email-masked]
--> Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt
--> 
--> Hi,
--> 
--> I'm trying to parse something out of this thread.
--> 
--> 1. It is clear that brpc *demands* that the sequence of domains
-->     is already known before brpc is executed.
-->     In my opinion, this is clear in the I-D, but it would 
--> not hurt to
-->     make it clearer.
-->     A statement in the Abstract and Introduction would achieve
-->     this.
--> 
--> 2. The mechanism by which the sequence of domains is known
-->     is out of scope for the procedure.
-->     It is not clear whether this is a limitation of the process, or
-->     not. But in my opinion this is consistent with the guidance
-->     that the WG received from the IAB when we were chartered.
-->     We are not trying to 'solve the Internet', so selection of
-->      domains is out of scope.
--> 
--> 3. brpc *does* include mechanisms for the selection of interdomain
-->     links and/or nodes. This is more complex than the 
--> simple selection
-->     of these points of attachment because the connection to use may
-->     depend on the TE paths within the domains.
-->     IMO, brpc is constructed specifically for this purpose. 
--> If we did
-->     not need this function, we could use pd-path computation with
-->     visibility of the inter-domain TE links.
--> 
--> 4. The discussion is not helped by debate about the precise wording
-->    around 'constraint'.
-->    Let us say that "the sequence of domains to be traversed is
-->    provided by an external source as a limiting factor to 
--> the computation
-->    or choice of paths."
--> 
--> Do we all agree with these statements?
--> 
--> Cheers,
--> Adrian
--> 
--> ----- Original Message ----- 
--> From: <[email-masked]>
--> To: "JP Vasseur" <[email-masked]>
--> Cc: <[email-masked]>; <[email-masked]>; 
--> <[email-masked]>
--> Sent: Monday, June 26, 2006 7:51 AM
--> Subject: 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
-->