>Do we all agree with these statements? Fully Agree
JL > -----Message d'origine----- > De : Adrian Farrel [mailto:[EMAIL PROTECTED] > Envoyé : lundi 26 juin 2006 15:14 > À : [EMAIL PROTECTED] > Cc : [EMAIL PROTECTED] > Objet : 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 PROTECTED]> > To: "JP Vasseur" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > 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 PROTECTED]> > > 26/06/2006 02:42 > > > > To: Dimitri PAPADIMITRIOU/BE/[EMAIL PROTECTED] > > cc: [EMAIL PROTECTED], [EMAIL PROTECTED], > > [EMAIL PROTECTED] > > Subject: Re: [Pce] Re: Comments on > > draft-vasseur-pce-brpc-00.txt > > > > > > hi dimitri, > > > > On Jun 25, 2006, at 7:35 PM, [EMAIL PROTECTED] wrote: > > > > hi j-p - see in-line > > > > > > > > > > JP Vasseur <[EMAIL PROTECTED]> > > 26/06/2006 01:14 > > > > To: Dimitri PAPADIMITRIOU/BE/[EMAIL PROTECTED] > > cc: "Adrian Farrel" <[EMAIL PROTECTED]>, > > [EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED] > > Subject: Re: [Pce] Re: Comments on > > draft-vasseur-pce-brpc-00.txt > > > > > > hi dimitiri, > > > > On Jun 25, 2006, at 2:08 PM, [EMAIL PROTECTED] 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 PROTECTED]> > > 23/06/2006 16:11 > > > > To: "Adrian Farrel" <[EMAIL PROTECTED]> > > cc: [EMAIL PROTECTED], [EMAIL PROTECTED], > > [EMAIL PROTECTED] > > 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 protected] > > https://www1.ietf.org/mailman/listinfo/pce > > _______________________________________________ > > Pce mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > _______________________________________________ > > Pce mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > _______________________________________________ > Pce mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
