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

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Wed, 28 Jun 2006 15:18:50 +0200

Hi Dimitri,

See inline, 

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] 
> Envoyé : lundi 26 juin 2006 17:09
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : JP Vasseur; [email-masked]; [email-masked]; 
> [email-masked]
> Objet : RE: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt
> 
> hi j-l - thanks for these clarifications - see in-line for a 
> couple of remarks
> 
> 
> 
> 
> "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
> 26/06/2006 16:37
>  
>         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,
>  
> Please see inline, 
> 
> > -----Message d'origine-----
> > De : [email-masked] 
> > [mailto:[email-masked]] 
> > Envoyé : lundi 26 juin 2006 15:43
> > À : JP Vasseur
> > Cc : [email-masked]; [email-masked]; 
> > [email-masked]
> > Objet : Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt
> > 
> > hi 
> > 
> > i don't think 1) and 2) have been captured 
> > 
> > on 1) there is a terminology issue - indeed - but there is 
> > also an issue that is the arbitrary selection/pruning of 
> > other potential alternatives - why that sequence ? and not 
> > another - was mentioned as the chicken-egg
> > (technical) problem; first there may be many available 
> > interdomain paths that are never learned by the LSRs, 
> >more 
> > generically the diversity of the BGP routes available at each 
> > LSR is not sufficient to successfully provide for a 
> > satisfactory sequence; on the other hand, you may have 
> > receive multiple let's take an example to illustrate there 
> > are two AS path between A and D, one A-B-C-D the other 
> > A-E-F-D disjoint (on intermediate ASs) either both sequences 
> > are valid both policing and filtering makes you selecting the 
> > inappropriate sequence for the real TE-LSP consrttaints
> 
> In the inter-AS case, inter-AS selection is likely to be driven by 
> business considerations and will be the result of (static or dynamic) 
> inter-SP service negociation and execution. Note that, as recalled by 
> Adrian, the objective is NOT to setup TE-LSPs over the Internet...
> Also in your example, one may simply run two BRPC with the 
> two AS-Path and 
> select the best result...
> 
> [dp] in the inter AS case, which is the most challenging, are 
> you telling 
> me that the whole policing and filtering is done but based on 
> information 
> elements that require further negotiation phases - such that your 
> selection is not susceptible to lead you to a case where the AS_path 
> doesn't provide you any further information but your initial 
> negotiation 
> makes it such that the probability of making the wrong selection is 
> minimized - taking the example i gave here above: two AS path 
> between A 
> and D, one A-B-C-D the other 
> A-E-F-D disjoint (on intermediate ASs) and both sequences are 
> valid - but 
> now policing and filtering makes you selecting the 
> appropriate sequence 
> for the real TE-LSP consrttaints ? 

Yes, this is what I meant

>if this is the case some further 
> inlightment may be really helpful -

This is already stated:

    "The domain path (set of domains traversed to reach the destination domain) is either administratively pre-determined or discovered by some means (outside of the scope of this document)".

There is nothing more to say in this draft IMO.

> 
> In the inter-area case, areas selection is straightforward.
> 
> > on 2) this is part of the answer - the comment was PCE per 
> > domain supporting that method - and in case of two PCEs or 
> > more per domain i am not sure how one could guarantee that 
> > the proposed (recursive) sequence works (assumption is made 
> > that the PCE as full visibility on the whole domain but what 
> > in case of multiple PCEs per domain)
> 
> If these PCEs have the same visibility then there is NO issue.
> If these PCEs don't have the same visibility, then actually you have 
> multiple sub-domains within the domain (or multiple domains 
> within a super 
> domain!), the pratical case being inter-AS path computation 
> where each AS 
> is made of several areas.
> Is that your concern?
> 
> [dp] my concern is that segmentation of PCE roles is not necessarily 
> mapping domain boundaries (intra-AS) 

Please note that in PCE terminology a "domain" is a generic term, this is a set of elements with a common sphere of path computation responsiblity (this is not limited to IGP areas, ASes). Hence the set of elements under PCE visibility is by definition a "domain", and segmentation of PCE roles IS mapping "domain" boudaries.
The procedures defined in this doc apply to multiple "domains", with this generic definition of "domains".

> and the other case is when for 
> instance could have as example that for a given "AS" a PCE 
> taking care of 
> TDM links and another ETH links hence you would have a 
> bifurcation - i 

Then you have at least two "domains" (one for TDM and one for ETH), and the procedures apply as is.

More generally when you have a hierachy of domains (e.g. AS domains, on top of area domains on top of techno domains) you need to run the BRPC procedure at each level.
When you run the BRCP procedure at level N you need to compute level N path segments, and this requires calling BRPC at level N-1, this is recursive.

Best Regards

JL

> mean you get a sequence of AS from routing but for each AS 
> there may be a 
> set of PCE which not structured such as to map the routing 
> topology - i 
> can rephrase as for a sequence of AS there can be multiple 
> sequences of 
> PCEs if these have not complete view you need to deal with 
> intermediate 
> recombination of information on the return path or make a 
> selection of 
> PCEs on the forward path - the doc. currently says "If 
> multiple PCEs are 
> discovered, the PCE may select a subset of these PCEs based 
> on some local 
> policies/heuristics." what in case it doesn't ?
> 
> In this situation, the inter-AS BRPC procedure triggers a set of 
> inter-area BRPC procedures in each AS to compute intra-AS (ie 
> inter-area) 
> path segments in each AS. 
> 
> Regards,
> 
> JL
> 
>  
> 
> Regards
> 
> JL
> 
> 
> > 
> > i have also asked to have a better description of the working 
> > conditions along this draft - to complete section 5.1 - 
> > 
> > if you consider this as non-technical or technical feedback 
> > that's your own appreciation 
> > 
> > thanks,
> > - dimitri.
> > 
> > 
> > 
> > 
> > 
> > 
> > JP Vasseur <[email-masked]>
> > 26/06/2006 14:54
> > 
> >         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,
> > 
> > ok so to summarize there was no technical feed-back just a 
> > few editorial comments. 
> > 
> > You'd like to add to the following to the document:
> > 1) The set of traversed domains has to be known and according 
> > to you this is not a constraint.
> > I think that the current text is quite clear:
> > "The BRPC procedure guarantees to compute the optimal path 
> > across a specific set of traversed domains (which constitutes 
> > an additional constraint)."
> > Now if you want to reword a bit to avoid using the word 
> "constraint" 
> > although this *is* a constraint, this is no big deal.
> > 
> > Actually, interestingly enough there are quite a few cases 
> > where there's only one single set of traversed domains.
> > 
> > 2) We need at least one PCE per domain
> > Sounds quite obvious but I have no problem adding this. 
> > Actually we're planning in the next revision to elaborate a 
> > little bit on the inter-As link flooding (again this is not a 
> > requirement but an optimization) but this will be covered.
> > 
> > JP.
> > 
> > On Jun 26, 2006, at 2:51 AM, [email-masked] wrote:
> > 
> > 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: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Jun 2006 16:05:06 +0100

JL

In line

Adrian

> This is already stated:
>
>    "The domain path (set of domains traversed to reach
>      the destination domain) is either administratively
>      pre-determined or discovered by some means
>     (outside of the scope of this document)".
>

Yes.

But this is in section 4.
I think that this could valuably be mentioned in the Abstract and in Section
3.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 29 Jun 2006 10:10:12 -0400

Hi,

Looks like we're converging, good. Cosmetic comments in line,

On Jun 28, 2006, at 9:18 AM, LE ROUX Jean-Louis RD-CORE-LAN wrote:

>     "The domain path (set of domains traversed to reach the  
> destination domain) is either administratively pre-determined or  
> discovered by some means (outside of the scope of this document)".
>
> Please note that in PCE terminology a "domain" is a generic term,  
> this is a set of elements with a common sphere of path computation  
> responsiblity (this is not limited to IGP areas, ASes). Hence the  
> set of elements under PCE visibility is by definition a "domain",  
> and segmentation of PCE roles IS mapping "domain" boudaries.
> The procedures defined in this doc apply to multiple "domains",  
> with this generic definition of "domains".

Right, as stated in the ID:

- Each AS can be made of several IGP areas.  The path computation
    procedure described in this document applies to the case of a single
    AS made of multiple IGP areas, multiples ASs made of a single IGP
    area or any combination of the above.  For the sake of simplicity,
    each AS will be considered to be comprised of a single area in this
    document.  The case of an Inter-AS TE LSP spanning multiple ASs  
where
    some of those ASs are themselves made of multiple IGP areas can be
    easily derived from this case by applying the BRPC procedure
    described in this document, recursively.

> More generally when you have a hierachy of domains (e.g. AS  
> domains, on top of area domains on top of techno domains) you need  
> to run the BRPC procedure at each level.
> When you run the BRCP procedure at level N you need to compute  
> level N path segments, and this requires calling BRPC at level N-1,  
> this is recursive.
>
> Best Regards

Thanks.

JP.