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