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

From: [email-masked]
Date: Thu, 6 Jul 2006 00:01:08 +0200

hi 

from the below exchange

"> Obviously, PCE(i-1) can compute the paths from each BR-en(i-1) to 
> each BR-ex(i-1), but in order to build the tree we need the paths 
> to be computed from each BR-en(i-1) to each BR-en(i). These paths 
> include the inter-domain TE links (where they exist).

This is actually not needed - see below

>
> So....
>
> Either there is an assumption that this TE link information is 
> available, or there is a step missing in the process.
>
> Perhaps the authors could clarify here and in the I-D.

OK let's clarify then.

The text in the draft says:

  Step i:

    - For i=n-1 to 2:

    PCE(i) concatenates the ASi topology (using its TED) with the
    received VSPT(i+1) and computes VSPT(i).

And this is where we could elaborate if you will. What PCE(i) has to 
do is to concatenate the received VSPT from PCE(i+1) to its ASi 
topology (by the way, there's a typo there, it should read "domain" 
rather than "AS") including the inter-AS TE links (in the case of 
Inter-AS). Once such operation is performed, it is quite easy to 
compute the new VSPT (MP2P tree) from each BN(j,i) and return it to 
the upstream PCE."

i read - assumption is that we need inter-AS link knowledge - 

response: no we don't don't but once explanations are provided we
notice that "including the inter-AS TE links" knowledge is required

so i am not sure that author's of this document clarified the real
issue that was initial pointed 

thanks,
- dimitri.

JP Vasseur <[email-masked]>
29/06/2006 16:09
 
        To:     Adrian Farrel <[email-masked]>
        cc:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, [email-masked]
        Subject:        Re: [Pce] Re: Comments on 
draft-vasseur-pce-brpc-00.txt

Hi Adrian,

Let me do this:
1) Reply to several emails individually
2) Send a summary to the list to make sure that all comments have 
been captured and will be addressed in the next revision.

See below,

On Jun 26, 2006, at 11:01 AM, Adrian Farrel wrote:

> Thanks Dimitri,
>
> This is converging nicely.
>
>> ok (nice summary) - i think the whole debate is on point 2) since 
>> last
>> meeting discussions - if one agrees that we don't solve this issue 
>> - then
>> being aware upfront/descriptive of limitations, conditions and 
>> workability
>> is really appropriated - let's assume this is (hopefully) the case
>
> Then that is an action for the authors to make points 1 and 2 
> *very* clear in the I-D (at the top!)

No problem to move some statement at the top ;-) Will do.

Here is the proposed new abstract:

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 along a determined sequence of domains, using a backward
    recursive path computation technique while preserving 
confidentiality
    across domains, which is sometimes required when domains are
    managed by different Service Providers.

>
>> the more important implication is point 3) - if this inter-domain 
>> link is
>> not provided - de facto - as part of the method what does this method
>> really provides ? i mean section 7. reads as if you can not flood 
>> just
>> makes PCE aware of that TE data; however, point on whether this 
>> info is
>> flooded or passed to the PCE or not the main issue is how this 
>> information
>> is locally obtained ? what does happen if this information is only
>> partially or not known, changing conditions, a unidirectional LSP 
>> reserves
>> bandwidth downstream how accounting occurs (edges need to be aware of
>> forward and reverse bandwidth), etc.
>
> I suspect you do not mean section 7?
>
> So, if I may rephrase....
> You are concerned about how the brpc process would operate if there 
> is an inter-domain link (e.g. inter-AS) and the TE information for 
> this link is not fully known.
>
> Let's quickly look at who needs to know.
>
> The downstream PCE provides paths from entry points to its domain 
> (BR-en(i)) to the destination. So the downstream PCE is not 
> interested in the TE links entering the domain.
>
> The upstream PCE provides paths from the entry points to its domain 
> (BR-en(i-1)) to the destination. It computes these by computing 
> 'optimal' paths from each BR-en(i-1) to the destination [says the I- 
> D in step 2]. But this is highly unclear!
>
> Obviously, PCE(i-1) can compute the paths from each BR-en(i-1) to 
> each BR-ex(i-1), but in order to build the tree we need the paths 
> to be computed from each BR-en(i-1) to each BR-en(i). These paths 
> include the inter-domain TE links (where they exist).

This is actually not needed - see below

>
> So....
>
> Either there is an assumption that this TE link information is 
> available, or there is a step missing in the process.
>
> Perhaps the authors could clarify here and in the I-D.

OK let's clarify then.

The text in the draft says:

  Step i:

    - For i=n-1 to 2:

    PCE(i) concatenates the ASi topology (using its TED) with the
    received VSPT(i+1) and computes VSPT(i).

And this is where we could elaborate if you will. What PCE(i) has to 
do is to concatenate the received VSPT from PCE(i+1) to its ASi 
topology (by the way, there's a typo there, it should read "domain" 
rather than "AS") including the inter-AS TE links (in the case of 
Inter-AS). Once such operation is performed, it is quite easy to 
compute the new VSPT (MP2P tree) from each BN(j,i) and return it to 
the upstream PCE.

So I propose to rephrase as follows:

Step i:

    - For i=n-1 to 2:

    PCE(i) concatenates the topology of domain (i) (using its TED)
    with the received VSPT(i+1). In the case of Inter-AS TE LSP
    computation, this requires to also add the inter-AS TE links
    connecting the domain (i) to the domain (i+1).
    Then PCE(i) computes VSPT(i) (P2MP tree made of the shortest
    constrained paths between each BN-en(j,i) and the TE LSP 
destination).

Does that clarify ?

Thanks.

JP.

>
> Thanks,
> Adrian
>
>
>
>
>
>
>> "Adrian Farrel" <[email-masked]>
>> 26/06/2006 15:14
>> Please respond to "Adrian Farrel"
>>
>>        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>>        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

_______________________________________________
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: JP Vasseur <[email-masked]>
Date: Wed, 5 Jul 2006 18:11:30 -0400

hi,

> issue that was initial pointed

Several requests for clarifications were added.

The new text reads:

Step i:
- For i=n-1 to 2: PCE(i) concatenates the topology of domain (i)  
(using its TED) with the received VSPT(i+1). In the case of Inter-AS  
TE LSP computation, this requires to also add the inter-AS TE links  
connecting the domain (i) to the domain (i+1). Then PCE(i) computes  
VSPT(i) (P2MP tree made of the shortest constrained paths between  
each BN-en(j,i) and the TE LSP destination).

In the case of Inter-AS TE, this operation also includes the links  
connecting ASBRs of ASi and ASi+1.

The text clearly explains that Inter-AS TE link knowledge is required.

Is there something that you don't find clear enough ?

Thanks.

JP.

---

From: [email-masked]
Date: Thu, 6 Jul 2006 00:32:17 +0200

j-p

the question boils down to how the receiving domain deduces the correct TE 
links to perform the concatenation operation you are describing

thanks,
-dimitri.

06/07/2006 00:11
 
        cc:     [email-masked]

hi,

hi 

from the below exchange

So....

OK let's clarify then.

  Step i:

    - For i=n-1 to 2:

The new text reads: 

Step i:
- For i=n-1 to 2: PCE(i) concatenates the topology of domain (i) (using 
its TED) with the received VSPT(i+1). In the case of Inter-AS TE LSP 
computation, this requires to also add the inter-AS TE links connecting 
the domain (i) to the domain (i+1). Then PCE(i) computes VSPT(i) (P2MP 
tree made of the shortest constrained paths between each BN-en(j,i) and 
the TE LSP destination).

Thanks.

JP.

thanks,
- dimitri.

Hi Adrian,

Let me do this:

See below,

Thanks Dimitri,

Abstract

So....

OK let's clarify then.

  Step i:

    - For i=n-1 to 2:

Step i:

    - For i=n-1 to 2:

Does that clarify ?

Thanks.

JP.

Thanks,
Adrian

Hi,

Cheers,
Adrian

hi j-p - see in-line

hi dimitri,

hi j-p - see in-line

hi dimitiri,

"==
Section 5.1

since so far when

be sufficient."

[dp] ditto

Ah so we agree here :-)

Thanks.

JP.

thanks.

JP.

Hi,

Thanks,
Adrian

==

==

==
Section 4

OK fine

==
Section 4

==
Section 5

==

==
Section 5.1

==
Section 5.2

==
Section 5.2

==
Section 5.2

==
Section 7

==
Section 8

Section 10

==
Section 13

Indeed.

==

JP.

etc.
==

==