Subject: RE: RE : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

From: <[email-masked]>
Date: Mon, 15 Nov 2004 13:17:03 -0000

Hi Jean-Loius,
> 
> Hi Neil, all
> 
> We do not reinvent GMPLS here, we just list a set of 
> functional reqs, that may lead 
> to minor protocol extensions.
> By the way it seems that some of your objections applies to 
> GMPLS in general...
NH=>  Not really.  The co-cs mode forces some good behaviours in GMPLS which we fully agree with, eg
-	OOB control/management
-	cannot violate connectivity requirements of the traffic data-plane
-	fixed/known hierachy

The latter forced requirement of the co-cs mode means one can have functional decoupling between the layer networks.  It also means one can choose best-of-breed functional components for things like addressing, signalling, OAM, etc.  'Choose' is the key word here.

All of this becomes rather important when different operators wish to lease capacity off each other in a client/server relationship.
> 
> Regarding one of your previous comments, please note that 
> dynamic capacity update is a key requirement for many SPs. 
> Here is a simple motivation example:
> Let's assume for instance that a SP owns two IP networks, one 
> for business trafic (VPNs) and another for DSL aggregation, 
> both supported by the same transmission network; these two 
> networks are not loaded during the same time along the day, 
> and it would be highly useful to share transport capacity 
> between them and reallocate bandwidth dynamically (with a 
> period of several hours).
NH=> I don't dispute this at all.  The key things are:
-	the timescales over which topology changes are effected (ie closer to the duct the slower the TE time-constants).....but in any case we are talking S-PVCs here IMO and not SVCs (at least for the forseeable future).
-	whether we are talking intra-operator or inter-operator.  As a representative of FT I would expect you to fully understand that what is advertised and/or allowed to be controlled in your network(s) is a very different issue in these 2 cases.
> 
> Note that the term "Toplogy" is relative. When you signal a 
> new TDM LSP between two routers, you may update the "IP 
> topology", as you setup a new IP link. This is just a 
> question of terminology.
NH=> Well, maybe....depends on how you are looking at this compared to myself.  As per your example, when you signal a new SDH VC4 layer network trail say between 2 nodes in the IP layer network (ie a link connection here) then of course you are changing the IP layer network topology.  What I am arguing is that you cannot simply create topology on the fly (ie as some top level demand rippling right down to the optics/duct say) in any viable commercial manner.....esp in the inter-operator case.  That is, one would create the link-connection in the client topology as a consequence of longer-term trends in traffic behaviour in the client....and when we start getting down the stack, with all the will in the world, it will be not possible to create a link connection where physical infrastructure does not exist.  So at what the level and to what degree is a priori provisioning done becomes a key question.  Further, I also firmly believe that strong functional decoupling is is important when we have a client/server relationship between 2 different operators.....and I'd be amazed if FT held any different view here.

regards, Neil
> 
> Best Regards,
> 
> JL
> 
> >-----Message d'origine-----
> >De : [email-masked]
> >[mailto:[email-masked]] De la part de 
> [email-masked]
> >Envoyé : lundi 15 novembre 2004 11:36
> >À : [email-masked]; [email-masked]; 
> >[email-masked]; [email-masked]
> >Objet : RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> >
> >
> >John,
> >
> ><snipped>
> >> > .....in fact a large supplier of ours recently admitted
> >> (after 3 years
> >> > of trying to persuade us otherwise) that they now agree 
> with us on 
> >> > this.
> >> <John Drake>
> >> 
> >> It's not unusual for a vendor that is incapable of building 
> >> <something> to assert that <something> is a Bad IdeaTM.
> >NH=> Well, one could also look at this differently.....given
> >we worked out the facts several years ago on our own and 
> >nothing has happened since to show we were wrong, then one 
> >could say that we know this vendor is now at least trying to 
> >be honest with us on this issue.
> >> 
> >> > Those who think they can 'create topology on the fly' can
> >> believe in
> >> > this stuff if they like.....you will convince me the day I see a 
> >> > routing protocol lay a duct and light some fibre, till 
> then we'll 
> >> > stick with what we know is true.
> >> <John Drake>
> >> 
> >> We never said that GMPLS had a backhoe option.
> >NH=> Try this logic.....and this is only one example of a
> >given layered network sequence:
> >-	to run the ducts we need the back-hoe
> >-	to run the fibre we need the ducts in place
> >-	to run the SDH MS/RS we need the fibre in place
> >-	to run the SDH VC4 layer network we need the SDH MS/RS in place
> >-	to run IP/MPLS layer networks we need the VC4 layer network in
> >place.
> >
> >Do you see the logical dependency?  Put simply, one cannot
> >create topology on the fly....at some point in the above you 
> >are going have to assume some 'already in place/fixed' 
> >topology.  But it's not even as simple as that.......
> >
> >Let's consider some of the commercial issues here as they are
> >rather important.  Ever tried figuring out the design rules 
> >required in some co-cs transport network (like SDH VC4 or OTNs 
> >say) so that one can 'create a trail at will' (an SVC by any 
> >other name)....or at least to some acceptable GoS (Grade of 
> >Service), ie probability of capacity being available within an 
> >acceptable (to the client) time period post making demand?
> >
> >Folks should try it some time as the results are rather
> >illuminating. We did this with our traffic engineering maths 
> >group at the labs a few years ago.  Without going into the 
> >detail, if you want to be able to 'turn-up' seriously large BW 
> >trails on demand between various locations you are going to 
> >have a build a network that runs largely empty for most of its 
> >working life....now try getting a business case for this past 
> >the products/services/financial people ;-).
> >
> >And once one turns up a trail in some lower layer network, do
> >you seriously expect we operators will turn it off?
> >
> >Bottom-line...as one gets closer to the duct the holding time
> >of trails/topology must increase.
> >
> >Note - These issues are over/above the requirement for
> >commercial/functional isolation between different operating 
> >parties in a client/server layer network relationship.
> >
> >regards, Neil
> >
> >
>

---

From: [email-masked]
Date: Mon, 15 Nov 2004 16:47:39 +0100

All,

few comments on this,

[email-masked] a écrit :

<snipped>

> -       the timescales over which topology changes are effected
> (ie closer to the duct the slower the TE time-constants).....but in
> any case we are talking S-PVCs here IMO and not SVCs (at least for
> the forseeable future).

MRN gives you the capability to take wise decisions
regardless of the time you need to take them.

> -       whether we are talking intra-operator or inter-operator.

AS JL said, intra, for the moment.

> As a representative of FT I would expect you to fully understand
> that what is advertised and/or allowed to be controlled in your
> network(s) is a very different issue in these 2 cases.
> >
> NH=> Well, maybe....depends on how you are looking at this compared
> to myself.  As per your example, when you signal a new SDH VC4 layer
> network trail say between 2 nodes in the IP layer network (ie a
> link connection here) then of course you are changing the IP layer
> network topology.  What I am arguing is that you cannot simply create
> topology on the fly (ie as some top level demand rippling right down
> to the optics/duct say) in any viable commercial manner.....esp in the
> inter-operator case.

I think there is sort of a misunderstanding here,
MRN does not mandates traffic driven connection establishment
(which is what I understand by "on the fly")
I gives the operator the full view of its switching capabilities so as
to intelligently trigger (if needed) additional resources.
But more generally, why are we focusing on triggering here,
MRN is, but is also much more than an enabler for intelligent
triggering through regions.

> That is, one would create the link-connection in the client topology
> as a consequence of longer-term trends in traffic behaviour in the
> client....and when we start getting down the stack, with all the will
> in the world, it will be not possible to create a link connection
> where physical infrastructure does not exist.  So at what the level
> and to what degree is a priori provisioning done becomes a key
> question.  Further, I also firmly believe that strong functional
> decoupling is is important
> when we have a client/server relationship between 2 different
> operators.....and I'd be amazed if FT held any different view here.

On the other hand, decoupling and region isolation would go against
efficient network engineering especially in intra-operator case
and distributed CP environment.

Finally I think that the topics covered here are more
in the scope of operational processes, which in turn 
are outside the scope of the mrn-reqs document.

Regards,

Martin

---

From: Kohei Shiomoto <[email-masked]>
Date: Tue, 16 Nov 2004 11:02:05 +0900

Hi Neil, all

INMO, resources in multiple regions could be optimized using GMPLS 
protocols (note: region means the domain in which the same switching 
technology is used). The time-scale of optimization is based on 
carriers' policy.

See inline for additional response.

>All of this becomes rather important when different operators wish to lease capacity off each other in a client/server relationship.
For the time being, the intra operator is the first target.

>-	whether we are talking intra-operator or inter-operator.  As a representative of FT I would expect you to fully understand that what is advertised and/or allowed to be controlled in your network(s…
As replied above, the intra operator is the first target. But as you 
said, confidentiality is a issue when we go further into the 
inter-operator case.

>NH=> Well, maybe....depends on how you are looking at this compared to myself.  As per your example, when you signal a new SDH VC4 layer network trail say between 2 nodes in the IP layer network (ie a link connection here) then of course you are changing the IP layer network topology.  What I am arguing is that you cannot simply create topology on the fly (ie as some top level demand rippling right down to the optics/duct say) in any viable commercial manner.....esp in the inter-operator case.  That is, one would create the link-connection in the client topology as a consequence of longer-term trends in traffic behaviour in the client....and when we start getting down the stack, with all the will in the world, it will be not possible to create a link connection where physical infrastructure does not exist.  So at what the level and to what degree is a priori provisioning done becomes a key question.  Further, I also firmly believe that strong functio
>nal decoupling is is important when we have a client/server relationship between 2 different operators.....and I'd be amazed if FT held any different view here.
>  
>
When considering the intra-operator case, optimizing resources in 
multiple regions should be easier than inter-operator case. Again we 
should note here that the term "Toplogy" is relative. When you set up or 
tear down a new TDM (or LSC, FSC)  LSP for instance between IP routers, 
you may reconfigure the "IP topology". How and when the "topology" is 
reconfigured depends on carrier's policy.

Such optimization of resources in multiple regions is feasible using 
GMPLS-based unified control plane (note again: region means the domain 
in which the same switching technology/capability is used). I think that 
it is worth to seek

Thank you for your comments.

-- 
Kohei Shiomoto
NTT Network Service Systems Laboratories
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
Phone +81 422 59 4402    Fax +81 422 59 4549