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

[John Drake <jdrake@calient.net>]

> -----Original Message-----
> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> Sent: Friday, November 12, 2004 8:29 AM
> To: dbrungard@att.com; sdshew@nortelnetworks.com; ccamp@ops.ietf.org
> Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> Hi Deborah,
> 
> Just to reassure you, I can confirm we fully understand what func arch is
> and why its important (we had a big hand in doing it).  And we also
> understand what GMPLS and MPLS are, what the 3 networking modes are, and
> how they are and are not related.
<John Drake>

Then I'm sure you are aware that the concept of a multi-region network (nee
the peer model) was an integral part of GMPLS from its inception, and that
it solves a very real problem with layered networks, viz, the problem of IGP
flooding in mesh networks.  I'm also sure you are aware that the deployment
of a layered network (nee the overlay model) or a multi-region network is at
the sole discretion of the owner of that network.


> One cannot functionally crunch the
> modes from 'IP to optics', it will simply not work either technically or
> commercially
<John Drake>

Late breaking news from Neil.  I better update my customers.

> .....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.

> 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.

> 
> regards, Neil
> 
> 
>  -----Original Message-----
> From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com]
> Sent: 12 November 2004 15:23
> To: Harrison,N,Neil,IKR2 R; sdshew@nortelnetworks.com; ccamp@ops.ietf.org
> Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> 
> 
> 	Hi Neil,
> 
> 	As I said in my previous mail, there seems to be confusion for those
> not familiar with GMPLS terminology. LSP is control plane. Nothing new
> here in this draft. I would suggest those concerned should discuss via the
> ITU-T SG 15 Q12/Q14 lists as the same choices were made for ITU's DCM
> (G7713.2 and G.7713.3) protocols.
> 
> 	Deborah
> 
> 
> 
> ________________________________
> 
> 	From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
> Behalf Of neil.2.harrison@bt.com
> 	Sent: Friday, November 12, 2004 8:41 AM
> 	To: sdshew@nortelnetworks.com; ccamp@ops.ietf.org
> 	Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> 
> 	Folks should take note of this advice.  We are fully in agreement
> with you on this issue Stephen.
> 
> 	BTW - G.805/809 stuff is not something dreamed-up in ITU just for
> the sake of it.....in fact its really nothing to do with ITU as its simply
> a formal way of capturing/defining the nature of real networks.
> 
> 	regards, Neil
> 
> 		-----Original Message-----
> 		From: owner-ccamp@ops.ietf.org [mailto:owner-
> ccamp@ops.ietf.org] On Behalf Of Stephen Shew
> 		Sent: 11 November 2004 20:02
> 		To: ccamp@ops.ietf.org
> 		Subject: Comment on
draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> 
> 		I was not able to be at the CCAMP meeting today but do have
> some comments on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt
> 
> 		It seems that the goals of the draft could be accomplished
> more simply by adopting the layer architecture as defined in ITU-T
> Recommendations G.805 and G.809.  By doing this, the specific boundaries
> between TDM, LSC, etc. don't have to be articulated as they are just layer
> networks.  Also, the designation of TDM does not include the notions of
> the layers within that (e.g., DS3, STS-1, VC4, etc.) which are important
> to transport equipment.  Adopting the layer architecture also enables a
> client layer to be supported by an inverse multipling layer such as
> provided by Virtual Concatenation.  Here a layer of finer granularity is
> use to support a layer of coarser granularity.
> 
> 
> 		Stephen Shew         Voice: 613-763-2462  Fax: 613-763-8385
> 		Nortel - Optical Networks  email: sdshew@nortelnetworks.com
> 		P.O. Box 3511, Station C
> 		Ottawa, ON K1Y 4H7
> 
>