hi j-l
"LE ROUX Jean-Louis RD-CORE-LAN" <[EMAIL PROTECTED]>
26/06/2006 09:03
To: Dimitri PAPADIMITRIOU/BE/[EMAIL PROTECTED], "JP Vasseur"
<[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: RE: [Pce] Re: Comments on
draft-vasseur-pce-brpc-00.txt
Hi Dimitri,
[dp] i read this, mind you, my point is that this is not a "constraint" of
the same nature as the one you're making use such as minimize delays or
whatsover - this constraint is introduced from the computation technique
and mechanism of this proposed method
No, this is not introduced from the path computation technique.
The AS-path is a constraint of the same nature as link/node inclusion,
this is actually a set of abstract nodes to be included.
[dp] but not for the same reason - isn't it ? -
By the way "minimze the delay" is NOT a constraint, this is an objective
to achieve...
[dp] i meant "maximum/minimize delay"
Thanks,
JL
> -----Message d'origine-----
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Envoyé : lundi 26 juin 2006 08:51
> À : JP Vasseur
> Cc : [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Objet : 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
