Subject: RE : [Pce] PCE Disco Reqs v01

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Tue, 5 Jul 2005 09:12:02 +0200

Hi Dimitri
 
Thanks for these valuable comments
 
Please see inline

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : samedi 2 juillet 2005 16:26
À : LE ROUX Jean-Louis RD-CORE-LAN
Cc : [email-masked]
Objet : Re: [Pce] PCE Disco Reqs v01

hi jean-louis

thanks for the update, i have the following comments/feedback

1. in the introduction you refer to "some relevant PCE" and it is important to be more accurate since this plays a specific role in the discovery context of this document
[JLLR]  Yes, it means PCE for inter-domain path computation, we will clarify in next revision 

2. in the same section the document mentions MPLS-TE and GMPLS capable PCEs, i wonder whether you not simply mean here path computed such as to be subsequently used by RSVP-TE and GMPLS RSVP-TE taking into accound specific set of constraints that can be used by such PCEs; 
[JLLR] Yes, I think that this is clear for everyone isn't it?

 also i think there is an inclusion relationship that should be pointed out here as the latter (a GMPLS-capable PCE) is by definition an MPLS- capable PCE
[JLLR] Agree 

3. section 5.1.2 it is unclear from this section whether the proposed discovery mechanism still allows for having multiple PCEs scoping a set of overlapping domains; 
[JLLR] The answer is yes, 
[JLLR] But actually this is a question more related to the PCE architecture itself. It depends on what you mean by overlapping. In the inter-area context for instance there is some overlapping between domains as ABRs belong to two or more domains.

 and in particular when X PCEs scope a single domain how it is possible to target a given PCE if there scope in terms of reachable prefixes is non-overlapping
 
[JLLR] You raise a good point, we should add discovery of domain(s) towards which a PCE can compute a path

For instance in the example of section 4, R9 is a composite PCE that can take part in inter-AS path 
computation, responsible for path computation in AS1 towards AS2. PCCs has to dynamically discover R9 as a PCE for inter-AS path computation as well as its path computation domain: AS1, and the domain towards which it can compute paths: AS2 

This will be added in next revision.

4. section 5.1.3 refers to the capability to handle "request prioritization" but it is unclear to which priority you are referring is this a specific and explicit information element as part of the request itself ? 
[JLLR] Yes it is

Note that actually capability description is out of the scope of this document, and should be addressed in a separate doc

 or an implicit prioritization mechanism based on the requestor identity, the type of request it initiates, etc

5. section 4 refers to the PCE liveness detection, there are two issues here where this 60s come from - why is there a need for emitting such liveness information every 60s ?
[JLLR] I agree that the requirement has to be reformulated. Actually what we want is a way to discover that a PCE is no longer alive under 60s, and this does not necessarily require emitting such information every 60s, this could be event driven by the way.

  beside the overhead such mechanism would generate it is rather unclear why a discovery mechanism has to ensure such keep-alive mechanism even for PCCs that do not make any use of the PCE(s) issuing this information

6. section 5.8 is simply outside of the scope of the present document, PCE selection is decoupled from their discovery
[JLLR] OK, this will be removed

By the way do you have any feedback on section 5.5?

Again thanks for these useful comments

Best Regards

JL 

thanks,

- dimitri.

"LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Sent by: [email-masked]
06/29/2005 14:00 ZE2

To: <[email-masked]>
cc: 
bcc: 
Subject: [Pce] PCE Disco Reqs v01

Hi all, 

Version 01 of the PCE discovery reqs ID has just been published 
http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-01.txt 

This version takes into account comments received during Minneapolis session and on the list. 

Here are the major changes since 00: 
-Added multi-area network case in the problem statement 
-Added application scenario (section 4) 
-Section 5.1 on capability discovery modified as per discussions on the list: 
        -Discovery of PCE location, PCE scopes and domain(s) under control is mandatory 
        -Capability discovery is no longer a MUST 
       The list of capabilities is now out of the scope and should be addressed in a 
       separate document. 
       
-Added section 5.6 on extensibility 
-Added Security section 

Section 5.5 (Discovery of PCE capacity and congestion) requires WG feedback: 
-Is there a need for the discovery of PCE capacity in terms of computation power? This static parameter could be used to ensure weighted load balancing of requests in case PCEs do not have the same capacity. 

-Would it be useful that a PCE report its status as "congested" in case it is too busy? PCCs may then use this dynamic information to prefer a different PCE. 

Your comments/feedback would be highly welcome, especially on the above point 

Best Regards, 

JL 

_______________________________________________
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: "Igor Bryskin" <[email-masked]>
Date: Wed, 6 Jul 2005 11:39:36 -0400

PCE Disco Reqs v01JL.

I have a couple of questions/comments.

1. On more than one occasions you use the term "TE-LSP path computation request". This sounds like an assumption that paths are computed separately for each TE-LSP. In reality, though, a single path computation request for a protected service is expected to determine paths for multiple LSPs (working and protecting). Furthermore, a single path computation may be performed for multiple services to make them possible sharing protection resources. I would suggest dropping the "TE-LSP" from the "TE-LSP path computation" combination;

2. In section 5.1.3 you mentioned among GMPLS capabilities a capability to compute multi-layer paths. This sounds inaccurate: paths are always computed in one network layer, however, a capable PCE may determine/suggest necessary reconfigurations in lower layer(s) in order to satisfy a particular path computation request;

3. I believe it should be stated more clearly that 2 stages of PCE discovery are needed: basic stage and detailed stage. During the basic stage PCE publishes some basic information about itself (presence, computation scope, etc.) on the network independently from PCCs. Interested PCCs should be able to participate in the detailed discovery stage, that is, to establish communication sessions (via PCC-PCE or a separate protocol) with the PCE to request/subscribe on the PCE detailed information (capability, CPU power, capacity, status, etc.). This would be good IMO both from the scalability and security points of view.

4. Responding to your questions:
        -Is there a need for the discovery of PCE capacity in terms of  
         computation power? This static parameter could be used to  
         ensure weighted load balancing of requests in case PCEs do not  
         have the same capacity. 
Yes. It could be achieved by a direct request from a PCC during the detailed discovery stage (see above).

        -Would it be useful that a PCE report its status as "congested"  
         in case it is too busy? PCCs may then use this dynamic  
         information to prefer a different PCE.  

Yes. It could be achieved by a subscription of a PCC on the PCE's status change (also during the detailed discovery stage ).

Cheers,
Igor

  ----- Original Message ----- 
  From: LE ROUX Jean-Louis RD-CORE-LAN 
  To: [email-masked] 
  Sent: Wednesday, June 29, 2005 8:00 AM
  Subject: [Pce] PCE Disco Reqs v01

  Hi all, 

         

  Best Regards, 

  JL 

------------------------------------------------------------------------------

---

From: "Igor Bryskin" <[email-masked]>
Date: Wed, 6 Jul 2005 13:33:42 -0400

Dimitri, see in-line.
  ----- Original Message ----- 
  From: [email-masked] 
  To: Igor Bryskin 
  Cc: LE ROUX Jean-Louis RD-CORE-LAN ; [email-masked] 
  Sent: Wednesday, July 06, 2005 12:08 PM
  Subject: Re: [Pce] PCE Disco Reqs v01

  igor, JL - a couple of comments:

  [dp] i would like to know how you have come to the second sentence statement - now more specifically, and in the context of the PCE discovery document, per [LSP-HIER] an incoming ERO may include the path to the lower SC, procedure is described in section 8.2 of that document so there is nothing wrong in that sentence it just need a clarification, that the sequence of hops resulting from this computation may be covering multiple LSP regions

  IB>> Come on, we had this argument many times already. Note, first, that neither me nor the document mentioned the term "region". Furthermore, a PSC LSP does not "go" through a lambda layer, rather, it uses H-LSPs created in the lambda layer as PSC data links. These links are no different from statically provisioned PSC links with an exception that the former could be installed and removed by the control plane. This is what I meant by the "lower layer re-configuration". The ERO subobjects associated with lambda switching capability is just one (and not the smartest IMO) way to control such re-configuration. An alternative way, for instance, would be for a PCE to assume the VNT manager role and request the lambda H-LSP provisioning *before* responding to the path computation request.

  [dp] not sure to understand why an "interested" PCC needs detailed information on the CPU and memory utilisation at the end why more classical "admission control" and "back pressure" mechanism can not be used here ?

  IB>> In this clause I didn't mean CPU or memory utilisation, rather, things like PCE sets of constraints that it can honor, optimization functions, diversity types, etc. 

  [dp] this is not the issue, even if the PCC knows the detailed computation power utilisation the significance of this information for the PCC itself can not tell to this PCC more than a "don't use" if it crosses a given threshold since the PCC does not know how much the request the PCC is going to initiate will consume on the PCE itself - there is an issue of the significance of the information that needs to be discussed first before requiring its initial or later stage discovery

  [dp] as also proposed by JL an event driven mechanism would be advisable 

  IB>> As the document states this information would help a PCC to choose most suitable PCE.

  Igor

  ----- Original Message ----- 
  From: LE ROUX Jean-Louis RD-CORE-LAN 
  To: [email-masked] 
  Sent: Wednesday, June 29, 2005 8:00 AM
  Subject: [Pce] PCE Disco Reqs v01

  Hi all, 

         

  Best Regards, 

  JL

---

From: [email-masked]
Date: Wed, 6 Jul 2005 20:20:15 +0200

igor

[dp2] that's not my point and the point is certainly not whether you can achieve or not the same functionality with other techniques - the issue is whether a PCE can be become a usable tool in the context of the CCAMP and MPLS signaling procedures then it needs to cover what these procedures have been defined as part of these documents otherwise one is going to be faced with the issue of a "GMPLS-capable PCE" that does not at the end provides the expected GMPLS/MPLS capabilities -

[dp2] the key issue is that "most suitable" becomes then a time-dependent problem at the end the discovery document could be simply state that there should be a mechanism that maintains (as part of its second stage exchange with the "subscribing PCCs") the liveness/status report of the initially "discovery information" without delving into the detailed implementation aspects

---

From: [email-masked]
Date: Thu, 7 Jul 2005 09:47:04 +0100

Igor wrote 06 July 2005 18:34

=== <snip>
2. In section 5.1.3 you mentioned among GMPLS capabilities a capability
to compute multi-layer paths. This sounds inaccurate: paths are always
computed in one network layer, however, a capable PCE may
determine/suggest necessary reconfigurations in lower layer(s) in order
to satisfy a particular path computation request;

[dp] i would like to know how you have come to the second sentence
statement - now more specifically, and in the context of the PCE
discovery document, per [LSP-HIER] an incoming ERO may include the path
to the lower SC, procedure is described in section 8.2 of that document
so there is nothing wrong in that sentence it just need a clarification,
that the sequence of hops resulting from this computation may be
covering multiple LSP regions.

IB>> Come on, we had this argument many times already. Note, first, that
neither me nor the document mentioned the term "region". Furthermore, a
PSC LSP does not "go" through a lambda layer, rather, it uses H-LSPs
created in the lambda layer as PSC data links.
=== <snip>

NH=> I am, quite frankly, amazed to find there are still some folks,
like Dimitri apparently, who believe in the fairy-tale that you can
create 'topology on the fly' in a set of layer networks.  You get the
same broken notion in PWE3 with the 'revelation' that a new layer
network (the PW layer) has been created and there is now a >=2 layer
network routing/signalling problem (and the rest function-wise) to
address.....never mind the madness of now having now created a
peer-partition interworking problem wrt XoverMPLS/LDP and XoverIP/l2tpv3
cases.  {Also see footnote reference if anyone wants to know more about
this and some of the points in what follows.}

And of course, as you rightly point out Igor a client layer link is
created by, and can only exist when there is, an *already* provisioned
server layer trail....and this client/server relationship is recursive
right down to the duct. This is how we create a client layer topology.
Indeed, with the additional requirement for client and server layer
functional decoupling, this is precisely what the well-known remark 'IP
over everything' demands.

Aside - Even if any folks are foolish enough dismisses the commercial
requirements for different party operating independence and the
technical issues relating to client/server layer network relationships,
I'd suggest they go try and build a business model for doing BoD trails
at large BWs (eg optics).  We did the math on this a few years
ago....think you may get an important conclusion.  Bottom-line: Trail
holding times must increase (and significantly so) as one approaches the
duct.

Now I think trying to calculate routes across a topology that does not
exist is very fine conjuring trick....maybe David Copperfield or David
Blaine might be interested in this illusion?  ;-) 

We are, however, very fortunate that co-cs mode protects itself to a
large extent against folks doing too many daft things to it.  For
example, you can't do merging violations, hierarchy is forced (so we can
have proper client/server layer functional decoupling), OOB
control/management is forced (which has important
resilience/stability/security design implications) and folks can't spend
lots of time/money creating a load of traffic/QoS classes that are
largely useless.  

Sadly the co-ps mode offers no such strong self-protection and you can
do all manner of bad things to it (I'll spare you a long list).
However, in the context of this mail and topic of 'topology on the fly',
you may like to note that MPLS is based on the concept of a digital
wrapper.  And if it's never struck you before just how bizarre this is
(and I'll point out right now that, so far, this has been essentially
latent, because when operating in a constrained operator/service
environment where the *effective networked* depth is 1 the wrapper
largely looks like a normal layer network), just note that in every
other case where we want to create a client layer network the server
layer trails (that provide the inter-node client layer links) MUST be
provided 1st...in other words the client goes inside an *already*
provided/existing server trail.  Now go look at MPLS....here we can 'add
a label at will' to an existing LSP and create a lower (outer) level
server layer trail AFTER our (inner) client layer trail exists.  Try
following that line of logic down to the duct and see what happens!  

However, our PWE3 colleagues seems more interested right now in arguing
the toss on 'LDP signalling vs RSVP-TE signalling' and don't seem to
see/grasp the deeper and far more serious issue here.

Anyway, it's nice to know there is at least one other person out there
Igor who seems to have a grip on reality (actually I know many folks who
do understand the points above....most however choose to remain silent
for one reason or another).

Footnote - If anyone is interested to learn more about the stuff I am
referring to here, please see my mail on a 'Network Builder Capability'
at http://www1.ietf.org/mail-archive/web/pwe3/current/msg07065.html

regards, Neil

---

From: [email-masked]
Date: Thu, 7 Jul 2005 11:00:48 +0200

neil - see in-line because we are not discussing the same issue

=== <snip>

NH=> I am, quite frankly, amazed to find there are still some folks,
like Dimitri apparently, who believe in the fairy-tale that you can
create 'topology on the fly' in a set of layer networks.

DP> neil, i just mention that the procedure for processing an ERO whose
hops cover multiple regions is described in section 8.2 of [LSP-HIER]; so
the issue is whether a PCE can be become a usable tool in the context of
the CCAMP and MPLS signaling procedures then it needs to cover what these
procedures have been defined as part of these documents otherwise one is
going to be faced with the issue of a "GMPLS-capable PCE" that does not
provides the expected GMPLS/MPLS capabilities - now, if for a set of
reasons (to be discussed) this mechanism is abandoned it should be first
reflected as part of the above mentioned document; at the end, the point,
is afaik that the PCE WG is not chartered to revise or select the signaling
procedures and mechanisms defined by the MPLS and CCAMP WG (but in case
extend them to cover its needs)

---

From: [email-masked]
Date: Thu, 7 Jul 2005 12:37:19 +0200

Neil

> neil - see in-line because we are not discussing the same issue
NH=> Its no use attempting to work on the roof of a house when the walls
and foundations are not in place...now please see below
>
> === <snip>
> 2. In section 5.1.3 you mentioned among GMPLS capabilities a
> capability to compute multi-layer paths. This sounds
> inaccurate: paths are always computed in one network layer,
> however, a capable PCE may determine/suggest necessary
> reconfigurations in lower layer(s) in order to satisfy a
> particular path computation request;
>
> [dp] i would like to know how you have come to the second
> sentence statement - now more specifically, and in the
> context of the PCE discovery document, per [LSP-HIER] an
> incoming ERO may include the path to the lower SC, procedure
> is described in section 8.2 of that document so there is
> nothing wrong in that sentence it just need a clarification,
> that the sequence of hops resulting from this computation may
> be covering multiple LSP regions.
>
> neither me nor the document mentioned the term "region".
> Furthermore, a PSC LSP does not "go" through a lambda layer,
> rather, it uses H-LSPs created in the lambda layer as PSC
> data links. === <snip>
>
>
> NH=> I am, quite frankly, amazed to find there are still some
> folks, like Dimitri apparently, who believe in the fairy-tale
> that you can create 'topology on the fly' in a set of layer networks.
>
> hops cover multiple regions is described in section 8.2 of
> [LSP-HIER]; so the issue is whether a PCE can be become a
> usable tool in the context of the CCAMP and MPLS signaling
> procedures then it needs to cover what these procedures have
> been defined as part of these documents otherwise one is
> going to be faced with the issue of a "GMPLS-capable PCE"
> that does not provides the expected GMPLS/MPLS capabilities -
> now, if for a set of reasons (to be discussed) this mechanism
> is abandoned it should be first reflected as part of the
> above mentioned document; at the end, the point, is afaik
> that the PCE WG is not chartered to revise or select the
> signaling procedures and mechanisms defined by the MPLS and
> CCAMP WG (but in case extend them to cover its needs)

NH=> Dimitri....Don't you think its a good idea to question whether
something is valid or not before acting on it?  It's not very wise IMO
(esp for a supplier) to follow stuff blindly if either (i) you don't
understand it and accept it on 'blind faith', or (worse) (ii) know its a
nonsense but carry on regardless.  And from your response above I'm not
quite sure which case applies here.

DP=> i am just say this goes beyond the scope of the PCE WG discussion on
requirement for the discovery protocol requirements

Can I therefore ask you specifically:

Do *you* believe (not what someone else has said) that we can have a
common/single instance of routing across all network modes/technolgies
such that on some client layer demand all the required layers below this
are magically installed....because without this there is no topology
basis in the client across which any routing decisions can be
calculated.  Noting that this remarkable routing instance must be
capable of:  digging trenches, laying ducts, installing fibres,
installing optics/SDH/whatever nodes, setting up lambda paths (say)
between SDH nodes (say), setting up VC4 paths (say) between VC12 (say)
nodes, installing client X nodes and setting up VC12 paths between
client X nodes, or whatever layer networks we wish to include in this
list...right up to the client who wishes to place a demand.  And this is
even in a SINGLE operator case.....goodness know how you reconcile this
when different operating parties own different layers.

DP=> what you depict here goes beyond what any unified or integrated
approach has ever considered which is typically the trigger of a VC-4 upon
a VC-12 incoming request or trigger a VC-4 upon an MPLS LSP request; what
you describe here above is really caricaturing the picture, an integrated
model is not meant to dig trenches or lay ducts or whatsoever; in brief, is
not the definition of an unified or integrated TE model

A simple yes or no answer will suffice.

DP=> so it yes, but not based on your definition

---

From: [email-masked]
Date: Thu, 7 Jul 2005 12:17:14 +0100

> DP=> what you depict here goes beyond what any unified or 
> integrated approach has ever considered which is typically 
> the trigger of a VC-4 upon a VC-12 incoming request or 
> trigger a VC-4 upon an MPLS LSP request; what you describe 
> here above is really caricaturing the picture, an integrated 
> model is not meant to dig trenches or lay ducts or 
> whatsoever; in brief, is not the definition of an unified or 
> integrated TE model

Is this documented anywhere?  It's been a while since I read through any
GMPLS/PCE drafts in detail, but I don't remember the scope of the
unified/integrated TE model being limited as you describe.

Where does this stop?  Are you saying that the scope is restricted such
that one layer (e.g. MPLS) may only trigger a connection/trail setup
event in its immediate server layer (e.g. VC-12)?  Then what is to stop
that immediate server layer (e.g. VC-12) triggering a connection/trail
setup event in it's immediate server layer (e.g. VC-4) and so on?  As
you can see this 'one layer triggering events in a lower layer'
behaviour is recursive to the duct (which I think is the point Neil was
trying to make).  Where is the line drawn and where is this 'line'
documented?

I would also question the commercials & economics of this approach, but
that is another argument/discussion entirely.  However if the
economics/commercials don't add up then no operator in their right mind
is going to deploy the unified/integrated TE model which I believe is
the crux of Neil's point regarding not following things blindly without
understanding its full impact.

Ben

-- 
Ben Niven-Jenkins
Networking Specialist, BT Exact

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Thu, 7 Jul 2005 11:07:49 -0500

Hi Ben, Neil,

My take, Dimitri's and Igor's debate is on the semantics if a
computation is one physical layer or multiple layers for a PSC LSP
comprising FA-LSPs (consisting physically of one or more server layers)
- especially for FAs dynamically triggered.

On (physical) multi-layer computation, there's multiple documents
covering GMPLS's integrated model including [3945]/8.3:
Path computation may take into account region boundaries when
   computing a path for an LSP.  For example, path computation may
   restrict the path taken by an LSP to only the links whose
   multiplexing/demultiplexing capability is PSC.  When an LSP need to
   cross a region boundary, it can trigger the establishment of an FA at
   the underlying layer (i.e., the L2SC layer).  This can trigger a
   cascading of FAs between layers with the following obvious order:
   L2SC, then TDM, then LSC, and then finally FSC.

The PCE generic requirements also included, as a deployment service
requirement, the need for multi-layer topology computation.

And ASON (G8080 Am2/6.5) on multi-layer defines the same concept of a
recursive control plane - and with no limits on recursion.

Is your concern more on how to manage the control plane's resources and
map the different TE information? This is the difficulty (for the
operator)- not the protocol aspects for triggering/computation. And I
agree without procedures (intra-domain and interdomain), the reality is
questionable. Actual policies are out of scope of this work, is there
text can add with more details on what's needed to ensure the pce can
support?

Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Thursday, July 07, 2005 7:17 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Pce] PCE Disco Reqs v01

Ben

---

From: [email-masked]
Date: Thu, 7 Jul 2005 19:50:54 +0100

Deborah....you don't seriously still believe in this stuff do you?  I
wonder if you understood my original post?

We CANNOT create topology on the fly...that is just a plain/obvious
truth.  But even if we ignore this fact there is still no strong
commercial/service basis for adding a control-plane to these networks
due to the long trail holding times required.  Do the math on the
business case for a reasonable BoD GoS and see what comes out...and
remember, even here in the layer network which is under consideration
for SVCs, all the kit both here and everything below this to the duct
MUST be already in place.....we can't route across links that do not
exist.  To help, here's a big hint from our traffic/maths modelling
folks:  Post-demand delay needs to be of at least the same order as the
expected holding time (hours/days/weeks/months?), and we don't have the
laws of large numbers here nor any good information of calling/holding
rates, so the modelling has to be quite general.  

The lion's share of the issues are related to the management-plane
anyway...and even if we add a control-plane this is still true, which
may be very disappointing news to some folk (and I am well aware this a
big area of concern for some operators, though we are fortunately not in
this position).

It does not apply for client/server layer network relationships when
different operating parties are involved....which is THE critical base
case to get right anyway.  I would not want to try telling some of our
major customers that they needed to peer (somehow) with our networks
(not that my own folks would even allow this anyway) when all they
wanted was a functionally decoupled network builder service from us.

And this is all in addition to all the stuff I pointed about regarding
the nonsense of topology on the fly.

In our view the main reason why adding a control-plane to large BW co-cs
mode networks is useful is to help automate provisioning under NMS
control (ie S-PVCs) and resilience. If you have better reasons that you
can justify then fine.....but I don't think folks should try and sell
this on the back of some flawed notion that we can create topology on
the fly across a set of layer networks from IP to Optics, as IMO this is
starting to border on being 'somewhat economical with the truth'. 

I normally don't bother responding to stuff in this area any more
because we've done our homework and know what the score is here.....but
I thought Igor might appreciate some support in trying to defend what
Dimitri said, because I did detect at least one voice of reason here
(though to reassure Igor, I know plenty of folks who do understand this
stuff, and you are far from alone, at least in other quarters).

Anyway, I'll leave you guys to it now.....

regards, Neil

> From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
> Sent: 07 July 2005 17:08
> To: Niven-jenkins,B,Ben,XDE73 R; 
> [email-masked]; Harrison,N,Neil,IKM1 R
> Cc: [email-masked]
> computation is one physical layer or multiple layers for a 
> PSC LSP comprising FA-LSPs (consisting physically of one or 
> more server layers)
> On (physical) multi-layer computation, there's multiple
> documents covering GMPLS's integrated model including 
> [3945]/8.3: Path computation may take into account region 
> boundaries when
> The PCE generic requirements also included, as a deployment
> service requirement, the need for multi-layer topology computation.
> 
> And ASON (G8080 Am2/6.5) on multi-layer defines the same
> concept of a recursive control plane - and with no limits on 
> recursion.
> 
> Is your concern more on how to manage the control plane's
> resources and map the different TE information? This is the 
> difficulty (for the
> operator)- not the protocol aspects for 
> triggering/computation. And I agree without procedures 
> (intra-domain and interdomain), the reality is questionable. 
> Actual policies are out of scope of this work, is there text 
> can add with more details on what's needed to ensure the pce 
> can support?
> 
> Deborah
> 
> 
> 
> 
>  
> 
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]

> > approach has ever considered which is typically the trigger of a 
> > VC-4 upon a VC-12 incoming request or trigger a VC-4 upon an MPLS 
> > LSP request; what you describe here above is really caricaturing the

> > picture, an integrated model is not meant to dig trenches or lay 
> > ducts or whatsoever; in brief, is not the definition of an unified 
> > or integrated TE model
> 
> Is this documented anywhere?  It's been a while since I read
> through any GMPLS/PCE drafts in detail, but I don't remember 
> the scope of the unified/integrated TE model being limited as 
> you describe.
> 
> Where does this stop?  Are you saying that the scope is
> restricted such that one layer (e.g. MPLS) may only trigger a 
> connection/trail setup event in its immediate server layer 
> (e.g. VC-12)?  Then what is to stop that immediate server 
> layer (e.g. VC-12) triggering a connection/trail setup event 
> in it's immediate server layer (e.g. VC-4) and so on?  As you 
> can see this 'one layer triggering events in a lower layer' 
> behaviour is recursive to the duct (which I think is the 
> point Neil was trying to make).  Where is the line drawn and 
> where is this 'line' documented?
> 
> I would also question the commercials & economics of this
> approach, but that is another argument/discussion entirely.  
> However if the economics/commercials don't add up then no 
> operator in their right mind is going to deploy the 
> unified/integrated TE model which I believe is the crux of 
> Neil's point regarding not following things blindly without

---

From: [email-masked]
Date: Thu, 7 Jul 2005 19:50:54 +0100

Hi Scott....
> Ben, as I said to your colleague a few weeks ago, even though 
> you cannot dig trenches you can present available resources 
> in different ways.
NH=> Can you please explain the scope/size of these idle resources
(noting that if they are not free you cannot use them), and who is
paying for them, that are sitting around waiting to be used?  Have you
actually tried to model this situation?  We have.

In any case, the technical observations I gave on how one builds a given
layer network's topology are accurate.  You know Alan McGuire here well,
so if you want a second opinion please talk to him.  I'll copy Alan in
so he is aware.

> Some client layers have a much easier 
> time of allocating resources if the resources are presented 
> to them already distinct, as opposed to having to manage the 
> multiplexing themselves.
NH=> Not sure I get this point.  Muxing belongs to the client->server
adaptation process.....but its the server that defines the muxing regime
(which is quite different for different network modes/technologies).  In
any case, the prior point remains, ie to what level of redundancy are
you willing to build out the server layer network so that a given client
on-demand request can be met in a *reasonable* time period?  For you as
a vendor this is not a problem, for me as an operator its a very
important issue.

>  So even though you cannot create 
> lower layer diversity in an upper layer, you can create 
> diversity for the layer(s) above you, and that does have merit.
NH=> This is a difference topic, ie that of performance and availability
inheritance.  Can go here if you want....big topic.

regards, Neil
> Scott