Subject: [CCAMP] Trying to resolve flexi-grid issue 1

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 12 Nov 2011 22:29:07 -0000

Hi,

I wanted to see whether we can prime the discussions of flexi-grid labels in
advance of the WG meetings this week.

It looks like we have successfully agreed that there are two significant
differences between the label formats defined in
http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-lambda-label
and http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid-rsvp-te-ext

The first point seems relatively minor:

Should we use a new value for the Grid field or should we continue to use the
value that indicates DWDM.

In favor of continuing to use the DWDM value is the fact that the ITU-T has not
defined a new grid for flexible wavelength assignments. In fact, the ITU-T says
that flexible assignments should be made from the DWDM grid.

On the other hand we need to understand that the fields in GMPLS objects exist
to make implementation easier and to convey information. There is no need for a
direct mapping to ITU-T grids.

Thus, when draft-zhang suggests using Grid==1 (ITU-T DWDM) it is correct that
the flexible grid wavelengths will be suggested from the ITU-T DWDM grid, but it
is not being as helpful as it could be.

When draft-farrkingel suggests using Grid==3 (ITU-T Flex) it is not implying
that there is a new and different grid defined by the ITU-T. What it is saying
is that the label is a flexi-grid label selected from the grid defined by the
ITU-T for that purpose (i.e., the DWDM grid).

Personally, i don't see this as a very large issue. draft-farrkingel would work
just as well if we decide to use Grid==1. however, I think it is marginally more
helpful and useful to be able to recognise the different label use cases (fixed
grid / flexible grid) by looking at a field early in the Label object.
Conversely, I don't believe that draft-zhang would be broken by using Grid==3.

So my compromise proposal is that both I-Ds use Grid==3. Then we can concentrate
on the more significant second issue (see separate email).

What do folk think?

Cheers,
Adrian

---

From: Dirk Schroetter <[email-masked]>
Date: Sun, 13 Nov 2011 05:01:48 +0200

Adrian,

I would concur with your analysis and support your proposal.

Cheers,

/Dirk

Sent from a mobile device. Please excuse any spelling errors.

Am 13.11.2011 um 06:36 schrieb "Adrian Farrel" <[email-masked]>:

> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Sun, 13 Nov 2011 08:24:56 +0100

Hi Adrian,

I think your proposal is reasonable. I don't see any particular issue in setting the Grid value to 1 or 3. Nevertheless the choice of value 3 is "more efficient" under the assumption that all the information (fixed grid or flexible grid) is included into the label...and this leads to issue 2.

Thanks and BR
Daniele

PS. @ Dirk: Congratulations for your automatic signature, the most clever i've ever seen :)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dirk Schroetter
Sent: domenica 13 novembre 2011 4.02
To: [email-masked]
Cc: [email-masked]
Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1

Adrian,

Cheers,

/Dirk

Am 13.11.2011 um 06:36 schrieb "Adrian Farrel" <[email-masked]>:

> Hi,
> 
> I wanted to see whether we can prime the discussions of flexi-grid 
> labels in advance of the WG meetings this week.
> 
> It looks like we have successfully agreed that there are two 
> significant differences between the label formats defined in 
> http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-lambd
> a-label and 
> http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid-rsvp-t
> e-ext
> 
> Should we use a new value for the Grid field or should we continue to 
> use the value that indicates DWDM.
> 
> In favor of continuing to use the DWDM value is the fact that the 
> ITU-T has not defined a new grid for flexible wavelength assignments. 
> In fact, the ITU-T says that flexible assignments should be made from the DWDM grid.
> 
> On the other hand we need to understand that the fields in GMPLS 
> objects exist to make implementation easier and to convey information. 
> There is no need for a direct mapping to ITU-T grids.
> 
> Thus, when draft-zhang suggests using Grid==1 (ITU-T DWDM) it is 
> correct that the flexible grid wavelengths will be suggested from the 
> ITU-T DWDM grid, but it is not being as helpful as it could be.
> 
> When draft-farrkingel suggests using Grid==3 (ITU-T Flex) it is not 
> implying that there is a new and different grid defined by the ITU-T. 
> What it is saying is that the label is a flexi-grid label selected 
> from the grid defined by the ITU-T for that purpose (i.e., the DWDM grid).
> 
> Personally, i don't see this as a very large issue. draft-farrkingel 
> would work just as well if we decide to use Grid==1. however, I think 
> it is marginally more helpful and useful to be able to recognise the 
> different label use cases (fixed grid / flexible grid) by looking at a field early in the Label object.
> So my compromise proposal is that both I-Ds use Grid==3. Then we can 
> concentrate on the more significant second issue (see separate email).
> 
> What do folk think?
> 
> Cheers,
> Adrian
>

---

From: Zhangfatai <[email-masked]>
Date: Mon, 14 Nov 2011 01:40:02 +0000

Hi Adrian,

From tech point of view, either way is OK for [draft-zhang] if there is no need for a direct mapping to ITU-T grids.

Thanks

Fatai

________________________________________
发件人: [email-masked] [[email-masked]] 代表 Adrian Farrel [[email-masked]]
发送时间: 2011年11月13日 6:29
到: [email-masked]
主题: [CCAMP] Trying to resolve flexi-grid issue 1

Hi,

What do folk think?

Cheers,
Adrian

---

From: [email-masked]
Date: Sun, 13 Nov 2011 21:11:18 -0500

Hi Adrian,

Interesting questions, but I think we need to consider the bigger picture 
first.  A few quick thoughts:

One motivation for the flexi-grid is to support the next generation 
optical signals (>100Gb/s) that cannot be efficiently accommodated with 
the current fixed grid.  However, we can expect to see flexi-grid deployed 
before these higher bit rate systems.

The current fixed grid provides an implicit guard band between optical 
channels (and slots can be left unused to allow a greater guard band). 
With flexi-grid we will probably need to specify the guard band.  The 
guard band will probably need to defined by a PCE application but we will 
need to define the parameters. 

Given that transiting an OADM narrows the optical bandwidth it may be 
possible to optimize the network by adjusting the requested bandwidth 
based on the number of OADMs in the path.  How would we "retain" this 
information to support restoration.

I expect that we will have a concatenation of flexi-grid and fixed grid 
links (managed via a PCE) in the network.  How will we signal for example 
for a slot to carry 10Gb/s signal across a network that includes the 
concatenation of fixed grid and flexi-grid segments.  The implication of 
routing (RWA) may also be interesting.

The flexi-grid will result in bandwidth fragmentation as traffic is added 
and removed from links.  We need to consider the need to defragment the 
link.

I think that the implications of flexi-grid go beyond signalling into 
routing (RWA).

The SG 15 will be meeting in December and will hold discussion on the use 
of the flexi-grid.  It would be useful to provide, either formally or 
informally a set of questions.

Regards,

Malcolm 

"Adrian Farrel" <[email-masked]> 
Sent by: [email-masked]
12/11/2011 05:29 PM
Please respond to
[email-masked]

To
<[email-masked]>
cc

Subject
[CCAMP] Trying to resolve flexi-grid issue 1

Hi,

I wanted to see whether we can prime the discussions of flexi-grid labels 
in
advance of the WG meetings this week.

and 
http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid-rsvp-te-ext

Should we use a new value for the Grid field or should we continue to use 
the
value that indicates DWDM.

In favor of continuing to use the DWDM value is the fact that the ITU-T 
has not
defined a new grid for flexible wavelength assignments. In fact, the ITU-T 
says
that flexible assignments should be made from the DWDM grid.

On the other hand we need to understand that the fields in GMPLS objects 
exist
to make implementation easier and to convey information. There is no need 
for a
direct mapping to ITU-T grids.

Thus, when draft-zhang suggests using Grid==1 (ITU-T DWDM) it is correct 
that
the flexible grid wavelengths will be suggested from the ITU-T DWDM grid, 
but it
is not being as helpful as it could be.

When draft-farrkingel suggests using Grid==3 (ITU-T Flex) it is not 
implying
that there is a new and different grid defined by the ITU-T. What it is 
saying
is that the label is a flexi-grid label selected from the grid defined by 
the
ITU-T for that purpose (i.e., the DWDM grid).

Personally, i don't see this as a very large issue. draft-farrkingel would 
work
just as well if we decide to use Grid==1. however, I think it is 
marginally more
helpful and useful to be able to recognise the different label use cases 
(fixed
grid / flexible grid) by looking at a field early in the Label object.
Conversely, I don't believe that draft-zhang would be broken by using 
Grid==3.

concentrate

What do folk think?

Cheers,
Adrian

---

From: Iftekhar Hussain <[email-masked]>
Date: Mon, 14 Nov 2011 02:48:38 +0000

Hi Malcolm,

Agreed with your observation about fragmentation in flexible grid. BTW, this is one of the reasons why we need to consider flexible approach for label definition that allows defragmentation (e.g., see  split-spectrum  super-channel option in  http://tools.ietf.org/html/draft-hussain-ccamp-super-channel-label-02).

Regarding consideration about guard-band, I think, it can be considered as a part of path computation constraint - does not necessarily need to advertise this as a part of routing.

Regards,
Iftekhar

From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, November 13, 2011 6:11 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1

Hi Adrian,

Interesting questions, but I think we need to consider the bigger picture first.  A few quick thoughts:

One motivation for the flexi-grid is to support the next generation optical signals (>100Gb/s) that cannot be efficiently accommodated with the current fixed grid.  However, we can expect to see flexi-grid deployed before these higher bit rate systems.

The current fixed grid provides an implicit guard band between optical channels (and slots can be left unused to allow a greater guard band).  With flexi-grid we will probably need to specify the guard band.  The guard band will probably need to defined by a PCE application but we will need to define the parameters.

Given that transiting an OADM narrows the optical bandwidth it may be possible to optimize the network by adjusting the requested bandwidth based on the number of OADMs in the path.  How would we "retain" this information to support restoration.

I expect that we will have a concatenation of flexi-grid and fixed grid links (managed via a PCE) in the network.  How will we signal for example for a slot to carry 10Gb/s signal across a network that includes the concatenation of fixed grid and flexi-grid segments.  The implication of routing (RWA) may also be interesting.

The flexi-grid will result in bandwidth fragmentation as traffic is added and removed from links.  We need to consider the need to defragment the link.

I think that the implications of flexi-grid go beyond signalling into routing (RWA).

The SG 15 will be meeting in December and will hold discussion on the use of the flexi-grid.  It would be useful to provide, either formally or informally a set of questions.

Regards,

Malcolm

"Adrian Farrel" <[email-masked]<mailto:[email-masked]>>
Sent by: [email-masked]<mailto:[email-masked]>

12/11/2011 05:29 PM
Please respond to
[email-masked]<mailto:[email-masked]>

To

<[email-masked]<mailto:[email-masked]>>

cc

Subject

Hi,

What do folk think?

Cheers,
Adrian

_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 14 Nov 2011 02:48:33 -0000

> The SG 15 will be meeting in December and will hold discussion on the
> use of the flexi-grid.  It would be useful to provide, either formally or 

Yes.
And it needs to be clear within CCAMP that we cannot (which is stronger than
must not!) get ahead of Q6/15.

At the risk of asking you to talk to yourself, it may be really helpful for you
to work with John Drake to build this list of questions.

A

---

From: [email-masked]
Date: Mon, 14 Nov 2011 11:13:04 +0800

Hi Iftekhar:

Please see below. 

[email-masked] 写于 2011-11-14 10:48:38:

> Hi Malcolm,
> 
> Agreed with your observation about fragmentation in flexible grid. 
> BTW, this is one of the reasons why we need to consider flexible 
> approach for label definition that allows defragmentation (e.g., see
> split-spectrum  super-channel option in  http://tools.ietf.
> org/html/draft-hussain-ccamp-super-channel-label-02).

<Yao>Actually, fragmentation will appear as traffic is 
 added and removed from links. The work of defragmentation should be left 
to computation entity like PCE. 
However, whether the slices will be switched with continuous form is not 
clear.

> 
> Regarding consideration about guard-band, I think, it can be 
> considered as a part of path computation constraint - does not 
> necessarily need to advertise this as a part of routing. 

<Yao> Agree.

> optical signals (>100Gb/s) that cannot be efficiently accommodated 
> with the current fixed grid.  However, we can expect to see flexi-
> grid deployed before these higher bit rate systems. 
> 
> The current fixed grid provides an implicit guard band between 
> optical channels (and slots can be left unused to allow a greater 
> guard band).  With flexi-grid we will probably need to specify the 
> guard band.  The guard band will probably need to defined by a PCE 
> application but we will need to define the parameters. 
> 
> Given that transiting an OADM narrows the optical bandwidth it may 
> be possible to optimize the network by adjusting the requested 
> bandwidth based on the number of OADMs in the path.  How would we 
> "retain" this information to support restoration. 
> 
> I expect that we will have a concatenation of flexi-grid and fixed 
> grid links (managed via a PCE) in the network.  How will we signal 
> for example for a slot to carry 10Gb/s signal across a network that 
> includes the concatenation of fixed grid and flexi-grid segments. 
> The implication of routing (RWA) may also be interesting. 
> 
> The flexi-grid will result in bandwidth fragmentation as traffic is 
> added and removed from links.  We need to consider the need to 
> defragment the link. 
> 
> The SG 15 will be meeting in December and will hold discussion on 
> the use of the flexi-grid.  It would be useful to provide, either 
> formally or informally a set of questions. 
> 
> Regards, 
> 
> Malcolm 
> 

> I wanted to see whether we can prime the discussions of flexi-grid 
labels in
> Should we use a new value for the Grid field or should we continue to 
use the
> ITU-T has not
> defined a new grid for flexible wavelength assignments. In fact, 
theITU-T says
exist
> to make implementation easier and to convey information. There is noneed 
for a
that
implying
> that there is a new and different grid defined by the ITU-T. What itis 
saying
> Personally, i don't see this as a very large issue. 
draft-farrkingelwould work
Grid==3.

---

From: [email-masked]
Date: Mon, 14 Nov 2011 11:22:07 +0800

Hi ALL:

Correct my mistake."whether the slices will be switched with continuous 
form is not clear." should be 
"whether the slices will be switched with uncontinuous form is not clear."

[email-masked] 写于 2011-11-14 11:13:04:

> added and removed from links. The work of defragmentation should be 
> left to computation entity like PCE. 
> However, whether the slices will be switched with continuous form isnot 
clear.
> > I wanted to see whether we can prime the discussions of 
flexi-gridlabels in
> > It looks like we have successfully agreed that there are two 
significant
> > Should we use a new value for the Grid field or should we continueto 
use the
> objects exist
> > to make implementation easier and to convey information. There is 
> noneed for a
> correct that
implying
> > that there is a new and different grid defined by the ITU-T. What 
> itis saying
> > Personally, i don't see this as a very large issue. draft-
> farrkingelwould work

---

From: Iftekhar Hussain <[email-masked]>
Date: Mon, 14 Nov 2011 03:25:10 +0000

Hi Yao,

Please see in-line

From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, November 13, 2011 7:13 PM
To: Iftekhar Hussain
Cc: Abinder Dhillon; [email-masked]; [email-masked]
Subject: [CCAMP] 答复: Re: Trying to resolve flexi-grid issue 1

Hi Iftekhar:

Please see below.

<Yao>Actually, fragmentation will appear as traffic is
added and removed from links. The work of defragmentation should be left to computation entity like PCE.
However, whether the slices will be switched with continuous form is not clear.

[Iftekhar] Yes, true, fragmentation will occur as a result of adding/removing optical LSPs.  I am not sure what you mean “defragmentation should be left to computation entity”. Why? How will PCE help in this regard – can you please elaborate.

Thanks,
Iftekhar

<Yao> Agree.

>
> Regards,
> Iftekhar
>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> defined a new grid for flexible wavelength assignments. In fact, theITU-T says
> to make implementation easier and to convey information. There is noneed for a
> that there is a new and different grid defined by the ITU-T. What itis saying
> Personally, i don't see this as a very large issue. draft-farrkingelwould work

---

From: [email-masked]
Date: Mon, 14 Nov 2011 11:40:29 +0800

Hi Iftekhar: 

 Please see inline. 
 
clear.

> [Iftekhar] Yes, true, fragmentation will occur as a result of 
> adding/removing optical LSPs.  I am not sure what you mean 
> “defragmentation should be left to computation entity”. Why? How 
> will PCE help in this regard – can you please elaborate.

<Yao> How to organize the fragmental slices into continuous ones is 
something like resources optimization. 
This can be done with PCE. While how to do it is implementation specific.
 
Thanks,
Yao Li

flexi-gridlabels in
significant
use the
implying

---

From: Iftekhar Hussain <[email-masked]>
Date: Mon, 14 Nov 2011 04:17:49 +0000

Please see in-line

From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, November 13, 2011 7:40 PM
To: Iftekhar Hussain
Cc: Abinder Dhillon; [email-masked]; [email-masked]; Marco Sosa; Vinayak Dangui
Subject: RE: [CCAMP] Trying to resolve flexi-grid issue 1

 Hi Iftekhar:

Please see inline.

> However, whether the slices will be switched with continuous form isnot clear.

> will PCE help in this regard - can you please elaborate.

<Yao> How to organize the fragmental slices into continuous ones is something like resources optimization.
This can be done with PCE. While how to do it is implementation specific.

[Iftekhar] I am not sure how defragmentation can be achieved with PCE alone.

Thanks,
Iftekhar

Thanks,
Yao Li

> > I wanted to see whether we can prime the discussions of flexi-gridlabels in
> > Should we use a new value for the Grid field or should we continueto use the

---

From: Huawei danli <[email-masked]>
Date: Mon, 14 Nov 2011 05:13:03 +0000

Maybe a stateful PCE is needed. Actually the defragmentation may cause the link resource adjustment, and then trigger the link be moved from one label to another label.

Dan

________________________________
发件人: [email-masked] [[email-masked]] 代表 Iftekhar Hussain [[email-masked]]
发送时间: 2011年11月14日 12:17
到: [email-masked]
Cc: Marco Sosa; Abinder Dhillon; [email-masked]; [email-masked]; Vinayak Dangui
主题: Re: [CCAMP] Trying to resolve flexi-grid issue 1

Please see in-line

 Hi Iftekhar:

Please see inline.

Thanks,
Iftekhar

Thanks,
Yao Li

---

From: Zhangfatai <[email-masked]>
Date: Mon, 14 Nov 2011 06:14:40 +0000

Hi Yao,

Agree with you.

I would like to describe what you said in another way:

Uncontinuous usage for the frequencies has not been defined (even mentioned) in ITU-T data plane.

Thanks

Fatai

________________________________
发件人: [email-masked] [[email-masked]] 代表 [email-masked] [[email-masked]]
发送时间: 2011年11月14日 11:22
到: [email-masked]
Cc: Abinder Dhillon; [email-masked]; Iftekhar Hussain; [email-masked]
主题: [CCAMP] 答复: 答复: Re: Trying to resolve flexi-grid issue 1

Hi ALL:

Correct my mistake."whether the slices will be switched with continuous form is not clear." should be
"whether the slices will be switched with uncontinuous form is not clear."

---

From: Zhangfatai <[email-masked]>
Date: Mon, 14 Nov 2011 06:24:40 +0000

Hi Yao,

Agree with you.

Uncontinuous usage for the frequencies is not defined (even mentioned) in ITU-T data plane.

Thanks

Fatai

Hi ALL:

---

From: Iftekhar Hussain <[email-masked]>
Date: Mon, 14 Nov 2011 18:06:35 +0000

Fatai,

ITU is defining the grid (frequencies). The allocation of frequencies is left to specific implementations and use cases. How did you infer that it precludes the use of split-spectrum use cases. Why one should impose artificial restrictions?

Iftekhar

From: Zhangfatai [mailto:[email-masked]]
Sent: Sunday, November 13, 2011 10:15 PM
To: [email-masked]
Cc: Abinder Dhillon; [email-masked]; Iftekhar Hussain; [email-masked]
Subject: 答复: [CCAMP] 答复: 答复: Re: Trying to resolve flexi-grid issue 1

Hi Yao,

Agree with you.

Thanks

Fatai

Hi ALL:

---

From: Giovanni Martinelli <[email-masked]>
Date: Tue, 15 Nov 2011 00:43:30 +0100

On 11/14/11 7:06 PM, Iftekhar Hussain wrote:
>
> Fatai,
>
> ITU is defining the grid (frequencies). The allocation of frequencies 
> is left to specific implementations and use cases. How did you infer 
> that it precludes the use of split-spectrum use cases. Why one should 
> impose artificial restrictions?
>
+1
G
>
> Iftekhar
>
> *From:*Zhangfatai [mailto:[email-masked]]
> *Sent:* Sunday, November 13, 2011 10:15 PM
> *To:* [email-masked]
> *Cc:* Abinder Dhillon; [email-masked]; Iftekhar Hussain; 
> [email-masked]
> *Subject:* 答复: [CCAMP] 答复: 答复: Re: Trying to resolve flexi-grid 
> issue 1
>
> Hi Yao,
>
> Agree with you.
>
> ------------------------------------------------------------------------
>
> *发件 人**:[email-masked] [[email-masked]] 代表 
> [email-masked] [[email-masked]]
> *发送时间**:*2011年11月14日11:22
> *到**:[email-masked]
> *Cc:* Abinder Dhillon; [email-masked]; Iftekhar Hussain; 
> [email-masked]
> *主题**:*[CCAMP] 答复: 答复: Re: Trying to resolve flexi-grid issue 1
>
>
> Hi ALL:
>
> Correct my mistake."whether the slices will be switched with 
> /continuous/ form is not clear." should be
> "whether the slices will be switched with /uncontinuous/form is not 
> clear."
>
> [email-masked] <mailto:[email-masked]> 写于 2011-11-14 
> 11:13:04:
>
> >
> > Hi Iftekhar:
> >
> > Please see below.
> >
> > [email-masked] <mailto:[email-masked]> 写于 
> 2011-11-14 10:48:38:
> >
> > > Hi Malcolm,
> > >
> > However, whether the slices will be switched with /continuous/ form 
> isnot clear.
> >
> >
> > >
> > > From: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] 
> <mailto:[mailto:[email-masked]]>
> > > To: [email-masked] <mailto:[email-masked]>
> > > Cc: [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> > > "Adrian Farrel" <[email-masked] <mailto:[email-masked]>>
> > > Sent by: [email-masked] <mailto:[email-masked]>
> > > 12/11/2011 05:29 PM
> > >
> > > Please respond to
> > > [email-masked] <mailto:[email-masked]>
> > >
> > > To
> > >
> > > <[email-masked] <mailto:[email-masked]>>
> > >
> > > cc
> > >
> > > Subject
> > >
> > > [email-masked] <mailto:[email-masked]>
> > > [email-masked] <mailto:[email-masked]>
> > [email-masked] <mailto:[email-masked]>