Subject: RE: [Pce] PCE Disco Reqs v01

From: [email-masked]
Date: Fri, 8 Jul 2005 09:55:56 +0100

Thanks Igor..... Please see in-line.

> 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.
NH=> OK
> 
> I agree that topology should be built bottom-up.
NH=> Well, no arguments from me as 'it's obviously true'.  However, I
have to emphasise that when creating topology in a set of nested layer
networks this cannot be driven solely by some idealistic 'common control
plane mindset'.....I know this is how the idea (of working on non-cl-ps
technologies) has been 'sold' to IETF to justify doing this stuff here,
but there are some crucial issues relating to:
-	the basic economics of network design (see my comments on GoS
design in previous mails, and its something I will return to repeatedly
below because its so important)...remember - someone has to ultimately
pay real money for this stuff
-	the differences between the 3 major modes of
networking.....these differences are actually the important
bits....which means we cannot have a truly 'common' approach in all
cases if we want to exploiut these differences to maximum advantage
-	the fact that for both scaling reasons and operating reasons
(which also contains facets like security and legal/regulatory
considerations for major opreators) functionally decoupled client/server
relationships are an ESSENTIAL starting point.  This is what I was
referring to in my earlier mail on a 'network builder capability'.  And
whilst this is ALWAYS achievable in the co-cs mode (purely due to the
modal constraints here)...and BTW this is also true for the cl-ps
mode..... this can be made NOT so in the co-ps mode if a digital wrapper
idea is used to create 'hierarchy' (which is precisely why folks are now
hitting problems with the multi-hop PW stuff based on MPLS).

So when we create topology using client/server layer network
relationships we MUST bear the above points in mind.  Now if I was to
make some very general observations on the architectural/commercial
design rules that should govern our thinking here, they would run along
these lines:
-	don't try and seek complete functional convergence across all 3
networking modes....use their differences wisely to solve (what could
be) otherwise very hard problems (like QoS, security, etc)
-	don't have lots of technologies belonging to the SAME mode....as
they will simply be replicating each other's modus operandi and it will
lead to (i) the so-called stove-pipe problem (ie a vertically complete
(ie inc NMS/OSS) networking platform where 'the technology' effectively
becomes 'the service' and (ii) nasty peer-partition
interworking/migration problems
-	recognise that as we move down towards the duct the
holding-times of trails will, of necessity, increase.....the converse is
also true
-	recognise that as we move down towards the duct the 'routing'
function becomes far less important than in the higher layer
networks.....or more generally, there is less need for a control-plane
than having a good management-plane story.  This does NOT mean we don't
need a control-plane here, eg signalling is a useful function, but the
time constants of the topology here are such (ie long of commercial
necessity) that the routing function (whilst still required) is far less
important than other components

> I also think
> that path computation for a particular LSP (connection) 
> should be constrained to the network layer where the LSP is 
> provisioned,
NH=> Yes, agreed again.  This is indeed a critical design requirement,
ie we MUST always be able to run each layer network independently from
other layer networks.  This is also a clear recognition that there
cannot be a singular control-plane...or more accurately a singular
routing instance (which, by definition, means there is no single
'addressing' instance across each of the layer networks).

> and it could succeed only if there is necessary 
> network flexibility (at least one that is advertised) in this 
> layer in place.
NH=> See my response to Scott.  But to summarise.....Who is actually
paying for all this idle BW at some layer N, and below which we agree
(as per above) everything from here on down MUST already be in place?
> 
> However, provided that the same instance of control plane 
> (e.g. GMPLS) manages multiple layers,
NH=> I have no problem with re-using the best-of-breed functional
components in each networking mode WHERE this is applicable, eg use the
same *base* signalling protocol and OOB solution for both the co-cs and
co-ps modes (the word 'base' is highlighted here to indicate that the
message set is not identical for each mode).....in fact I strongly
encourage this type of practice.  Where I do object however is when
folks try and tell me there is a 'common' instance of functional
components running from top to bottom.  This will neither work well per
se nor does it satisfy important commercial and operational
requirements.

> 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.
NH=> This seems to be asking me as an operator to build out some server
layer networks with lots of capacity just so as we can prove that a
given client can present some ad hoc demand to those server layer and
have it satisfied right?  And, as you agreed at the outset, below *this*
layer network (wherever this is) everything else must be already hard
provisioned.....because, as we agreed, topology is created from the duct
upward.  Not only do I think this is commercially unrealistic without
some idea of the GoS one could realistically achieve (I have to pay to
build this GoS remember), I think it is underestimating (and very much
so) the impact, and relationship with, the management-plane.  I would
strongly advise having a talk to the folks in large operators who are
responsible for running and *paying* for their major transport networks
(eg SDH) rather than the folks from more of a 'R&D' background in those
operators....you may get a very different perspective on what is
important here and what is not.
 
> 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.
NH=> If I was being slightly cynical here I could say 'This reads like
the dawning of the realisation that it's network management that is key
here'.

> and instruct (if
> authorized) appropriate controllers to establish H-LSPs 
> (trails) and advertise them as TE links. 

NH=> I've never understood what these 'TE links' are......they are
woolly defined at best IMO.  What you appear to be describing is basic
G.805 stuff (if I have this right), ie you are creating a link in client
layer network using trails of some server layer network.  Fine, nothing
wrong with that.  But I'm sensing some desperation here to find a role
for this GMPLS stuff that has been generated.  For example, if client
layer network X does not need capacity during time T we can reallocate
that capacity to client layer Y.  Sounds nice in principle....ain't so
simple in practice (for many reasons, esp wrt the costs associated with
providing some *acceptable* on-demand GoS).  And as I observed earlier,
this looks to me as though its the dawning of the realisation that
network management is the key issue here....which of course it is.

> Only once the TE 
> links are advertised, the original path computation request 
> can succeed.
NH=> Very much so....at least wrt to my understanding of what 'TE links'
ought to mean in practice, ie you can't calculate routes over a topology
that does not exist.  But this all comes back to 'in which layer network
does the hard provisioning start?'  And then 'to what level of (client)
on-demand GoS is *that* server layer network supposed to be designed
against?'   And do you really think we need a control-plane solution to
provide this as we approach the duct (given the current realities of
commercial models of BoD)?  And what about client/server relationships
between different parties?  I actually think this work is now clutching
at straws to justify its continued existence.  Nice theoretical work
perhaps....and I could postulate some future where certain *public*
services in end-systems (based on large file transfer or stream
applications say) might be able to call-up some simple on-demand SVCs in
some co-cs or co-ps (here CBR-like) layer network (think of it as BB
PSTN if you like)....now that scenario might warrant closer scutinity
(in fact I'd say this is an area well worth looking at as it will
address some otherwise very hard QoS/pricing problems that will not be
satisfactorily solved by current direction).  However, as a private
network builder service capability in today's environment....whether
this is aimed at self-owned or other-party-owned client layer
networks.....I don't think this is currently that viable.  However it
does seem to be the basis on which you would sell this notion right now.

> 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.
NH=> Yes, but have you done the business case to warrant the build-out
creation of these underpinning transport layer networks that are there
sitting there idle waiting to satisfy these hopeful client layer
demands?  I was talking about this topic to one of my colleagues who has
done this type of study here in BT and we might see if we can publish
some of our findings.

>  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.
NH=> Withdrawn?!  I'll believe it when I see it.  IMO, no IM STRONG O,
if you provide some server layer capacity to a given client layer
network you will NEVER withdraw it (not unless the client is in
decline).....as it impacts that client layer's topology and what it (ie
the client layer network) does with route calculations from this moment
onwards.
> 
> Hope this helps rather that brings more confusion.
NH=> I think your engineering heart is in the right place Igor.  But I
think the commercial justifications are misplaced.  I don't know why we
can't have a simpler model of where we want to head wrt networking.  I
have a fairly clear model in my mind of what this ought to look like (so
we can all benefit), where all 3 networking modes work in concert across
private and public services, but I think we are some way off acheiving
this.  Maybe for another day a few years hence.

In the meantime, I'd suggest sitting down with the folks in large
operators who are really responsible for operating/designing and paying
for these major transport networks.

regards, Neil
> 
> 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,
> 
> > 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: Fri, 8 Jul 2005 11:02:23 -0400

Neil,

Thanks for your comments, they help a lot. See my comments in-line.

Igor

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, July 08, 2005 4:55 AM
Subject: RE: [Pce] PCE Disco Reqs v01

NH=> OK

IB>> Let me ask you something. Suppose we have VC12 layer and VC4 layer. Is
it unrealistic to expect that the same instance of the control plane manages
both of them? If, say, PCE fails a path computation for a VC12 connection,
could it suggest a reconfiguration in the VC4 layer, pass this suggestion to
a VNT Manager (application/entity that has security, budget, etc.
authorization) to add trails in VC4 layer and provide extra flexibility in
the VC12 layer? Correct me if I am wrong, but you sound like always require
NMS+human in the inter-layer relationships. Why the process could not be
autometed via control plane ?

NH=> Yes, agreed again.  This is indeed a critical design requirement,
ie we MUST always be able to run each layer network independently from
other layer networks.
IB>> This is not what I said (at least, meant). See the comment above.

  This is also a clear recognition that there
cannot be a singular control-plane...or more accurately a singular
routing instance (which, by definition, means there is no single
'addressing' instance across each of the layer networks).

IB>> Agaian, this is not what I meant..

IB>> An application/ architectural construct (I call it VNT Manager)
authorized to do so. This application has policies what to do with unused
BW. For instance, it decides what to do whith dynamically created trail when
the last client layer connection is gone.
NH=> I have no problem with re-using the best-of-breed functional
components in each networking mode WHERE this is applicable, eg use the
same *base* signalling protocol and OOB solution for both the co-cs and
co-ps modes (the word 'base' is highlighted here to indicate that the
message set is not identical for each mode).....in fact I strongly
encourage this type of practice.  Where I do object however is when
folks try and tell me there is a 'common' instance of functional
components running from top to bottom.  This will neither work well per
se nor does it satisfy important commercial and operational
requirements.
IB>> See my example above. Furthermore, GMPLS introduces a notion of
"region" for layers associated, say, with different data plane technology
where the bulk of control plane functionality is the same, but subtelties
needs to be performed differently (slightly different set of signaling
objects, different path computation constraints, etc.)

NH=> This seems to be asking me as an operator to build out some server
layer networks with lots of capacity just so as we can prove that a
given client can present some ad hoc demand to those server layer and
have it satisfied right?  And, as you agreed at the outset, below *this*
layer network (wherever this is) everything else must be already hard
provisioned.....because, as we agreed, topology is created from the duct
upward.
IB>> Nobody said that GMPLS must control all layers, it could control for
instance all/some SDH layers. Network topology in lower layers it does not
control, of course, needs to be in place.

 Not only do I think this is commercially unrealistic without
 IB>> Agree, this would be extreamely useful.

NH=> I've never understood what these 'TE links' are......they are
woolly defined at best IMO.
IB>> In the lexicography draft we (Adrian and myself) tried very hard to
explain what the TE link means. In ASON terminology it is SNPP link

  What you appear to be describing is basic
G.805 stuff (if I have this right), ie you are creating a link in client
layer network using trails of some server layer network.

IB>> Those are data links. GMPLS data link = ASON link supported by a single
trail in the server layer. Those are collection of network resources but not
something path computation works with. PCE works with graphs built of TE
links - logical grouping of resources.

 Fine, nothing

IB>> Again, this is upto VNT Manager to decide. Dynamically advertised TE
links surely could be withdrawn. It should be done with a caution not to
destabilize the client layer, but this still could be done.
IB>> Whould be very interested to see your model

regards, Neil

IB>> Cheers,  Igor