[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
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...
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).
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.
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
>
>