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

From: "Mack-Crane, T. Benjamin" <[email-masked]>
Date: Thu, 11 Nov 2004 15:20:51 -0600

Stephen,

This sounds like a good practical approach.

Ben

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Shew
Sent: Thursday, November 11, 2004 2:02 PM
To: [email-masked]
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: [email-masked] 
P.O. Box 3511, Station C 
Ottawa, ON K1Y 4H7

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Thu, 11 Nov 2004 16:24:16 -0600

Hi Stephen,
 
Thanks for your comments, we are glad to see the interest our draft is
receiving considering the original draft
(draft-vigoureux-shiomoto-ccamp-gmpls-mrn) submitted multiple times
since early 2003 did not;-) Our decision to split the document is
proving to have been a good move.
 
We had no intention in this draft to introduce any new terminology, we
are using the terminology from the base GMPLS documents and
draft-ietf-mpls-lsp-hierarchy. RFC3471 and lsp-hierarchy (Section 7.1)
defines LSP regions and boundaries i.e. control plane boundaries based
on the (GMPLS) interface switching type (i.e. PSC, L2SC, TDM, LSC, FCS).
We have adopted the ITU terminology of layer when referring to data
(transport) plane (also in the GMPLS base documents).
 
We asked at the meeting for comments to provide specific text pointers
(can send either privately or via the exploder).
 
I am not sure the meaning of your comment "adopt the layer architecture
of ITU"? As a similar comment was made at the meeting "GMPLS switching
capabilities are not aligned with ITU layering" and in a follow-up mail
by Eve, we repeat our response, this draft is not defining (new) GMPLS
switching capabilities (or architecture). The definition of GMPLS
switching capabilities is not within the scope of this draft - they are
defined in the base GMPLS documents. Any concerns should target the
appropriate document (RFC3473, ...). 
 
Deborah

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Shew
Sent: Thursday, November 11, 2004 3:02 PM
To: [email-masked]
Subject: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

---

From: <[email-masked]>
Date: Fri, 12 Nov 2004 13:40:40 -0000

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Shew
Sent: 11 November 2004 20:02
To: [email-masked]
Subject: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Fri, 12 Nov 2004 09:23:25 -0600

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: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Friday, November 12, 2004 8:41 AM
To: [email-masked]; [email-masked]
Subject: RE: Comment on draft-shiomoto-ccamp-gmpls-mrn-reqs-00.txt

 
regards, Neil

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Shew
	Sent: 11 November 2004 20:02
	To: [email-masked]
	Subject: Comment 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.

---

From: <[email-masked]>
Date: Fri, 12 Nov 2004 16:28:56 -0000

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.  One cannot functionally crunch the
modes from 'IP to optics', it will simply not work either technically or
commercially.....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.  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.
 
regards, Neil

 -----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]] 
Sent: 12 November 2004 15:23
To: Harrison,N,Neil,IKR2 R; [email-masked];
[email-masked]

Hi Neil,

Deborah

  _____  

 
 
regards, Neil

---

From: John Drake <[email-masked]>
Date: Sat, 13 Nov 2004 09:30:48 -0800

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, November 12, 2004 8:29 AM
> To: [email-masked]; [email-masked]; [email-masked]
> 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
> 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
> 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.

> To: Harrison,N,Neil,IKR2 R; [email-masked]; [email-masked]
> 	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
> 	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
> 
> 		From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of Stephen Shew
> 		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
> 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

---

From: <[email-masked]>
Date: Mon, 15 Nov 2004 10:35:35 -0000

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>
> 
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: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Mon, 15 Nov 2004 12:22:42 +0100

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 : [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>
>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.
>> 
>NH=> Try this logic.....and this is only one example of a 
>given layered network sequence:
>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.
>
>commercial/functional isolation between different operating 
>parties in a client/server layer network relationship.
>
>regards, Neil
>
>