Hi Neil
Not sure this discussion will help, actually this is out of the scope of this ID,
nevermind, see inline,
JL
-----Message d'origine-----
De : neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
Envoyé : lundi 15 novembre 2004 14:17
À : LE ROUX Jean-Louis RD-CORE-LAN; jdrake@calient.net;
dbrungard@att.com; sdshew@nortelnetworks.com; ccamp@ops.ietf.org
Objet : RE: RE : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
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).
No, why such restriction to S-PVCs, SVCs are largely envisageable in
an intra-operator case.
- 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.
Be sure I fully understand the distinction...
Here in this example I was talking intra-operator.
By the way, note that current MRN requirements focus on intra operator case.
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.
And what about the INTRA 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.
Please could you point where did you see such statement "to create a link connection
where physical infrastructure does not exist" in our draft ?
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.
Sure but who is talking about two operators here ?????
I think you missed something here. What about cases were both IP and transport are under the control of the same entity ????
Best Regards,
Jean-Louis
regards, Neil
Best Regards,
JL
-----Message d'origine-----
De : owner-ccamp@ops.ietf.org
[mailto:owner-ccamp@ops.ietf.org] De la part de
neil.2.harrison@bt.com
Envoyé : lundi 15 novembre 2004 11:36
À : jdrake@calient.net; dbrungard@att.com;
sdshew@nortelnetworks.com; ccamp@ops.ietf.org
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