Subject: RE: [Pce] PCE Disco Reqs v01

From: [email-masked]
Date: Thu, 7 Jul 2005 11:15:20 +0100

Dimitri,

> 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.
> 
> 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.
> 
> 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)

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. 

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.

A simple yes or no answer will suffice.

regards, Neil

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: "Igor Bryskin" <[email-masked]>
Date: Thu, 7 Jul 2005 14:48:09 -0400

Neil.

I'd like to explain a bit more my views on the network topology management
and why the discussion is IMO important in the PCE context.

I agree that topology should be built bottom-up. I also think that path
computation for a particular LSP (connection) should be constrained to the
network layer where the LSP is provisioned, and it could succeed only if
there is necessary network flexibility (at least one that is advertised) in
this layer in place.

However, provided that the same instance of control plane (e.g. GMPLS)
manages multiple layers, and PCE has sufficient TE visibility, and TE link
advertisements include such attributes as termination and adaptation
capabilities, PCE could determine necessary reconfigurations in lower
layer(s) in order to have original PCE request satisfied. This extra
information could be used by a special application (let's call it Virtual
Network Topology (VNT) Manager), which could verify that the specified
re-configurations are, indeed, feasible, optimal, do not affect active
services, do not cause network de-stabilization, etc. and instruct (if
authorized) appropriate controllers to establish H-LSPs (trails) and
advertise them as TE links. Only once the TE links are advertised, the
original path computation request can succeed. Note that the H-LSPs could be
virtual (not provisioned) or soft (resources are allocated but not bound
into cross-connects, they are shared with other LSPs or even carry extra
traffic) and become hard (that is, fully provisioned) when the Setup message
of the first LSP they suppose to carry arrives on the H-LSP ingress nodes.
The important thing is that TE links associated with such H-LSPs are
advertised and available for the original path computation. The VNT manager
also decides when the H-LSPs should be removed and associated TE links
withdrawn, so that the network is not de-stabilized by frequent
re-configurations.

Hope this helps rather that brings more confusion.

Igor

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, July 07, 2005 6:15 AM
Subject: RE: [Pce] PCE Disco Reqs v01

Dimitri,

regards, Neil