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 PROTECTED]>
29/06/2006 16:09
To: Adrian Farrel <[EMAIL PROTECTED]>
cc: Dimitri PAPADIMITRIOU/BE/[EMAIL PROTECTED], [EMAIL PROTECTED]
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 PROTECTED]>
>> 26/06/2006 15:14
>> Please respond to "Adrian Farrel"
>>
>> To: Dimitri PAPADIMITRIOU/BE/[EMAIL PROTECTED]
>> cc: <[EMAIL PROTECTED]>
>> 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 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
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
