Subject: Re: [CCAMP] Update to draft-farrkingel-ccamp-flexigrid-lambda-label

From: [email-masked]
Date: Thu, 22 Mar 2012 17:27:20 +0800

Hi, Fatai, Adrian and Iftekhar

It seems that flexible-grid network is becoming a hot topic in these days, 
but I also find that the discussions mainly focus on two problems listed 
as follows:

1. Where do we carry the "m" value, label or traffic parameters?

2. What should we discuss in the first step, the whole Flexible-Grid 
control plane or just label and signaling parameters?

Here I present my concept on these two qustions.

The first one, I absolutely agree with Adrian. "the view that "m" is part 
of the definition of what is being switched and is essential for the 
switch cross-connect to be programmed. Thus,it is part of the label." "I 
would acknowledge that the value of "m" influences the bandwidth of the 
LSP, but I would claim that an Path request asks for b/w in the traffic 
parameters and the label returned provides the value of "m" to be 
programmed into the XC. If it is necessary (perhaps a question 
fordraft-zhang-ccamp-flexible-grid-rsvp-te-ext) to also specify "m" (or a 
range of acceptable values of "m") as part of the Path request, then it 
would seem pragmatic to put it in the traffic parameters."

In my opinion, it may be reasonable to carry certain fields in traffic 
parameters that claim min slot width or slot width range the LSP requests, 
as well, it is also necessary to include "m" in the label to claim actual 
slot width assigned to this LSP. For example, assuming a flexible-grid 
network composed of optical components with 25GHz slot width granularity 
and [50GHz, 200GHz] slot width range. When a 25GHz-slot-width LSP request 
arrives, the signaling may add 25GHz in traffic parameters to claim the 
min slot width required. However, due to the Flexible-Grid capability 
limitation of optical components, the actual slot width assigned to this 
LSP may be 50GHz, which is added as "m" in the label. similarly, When a 
87.5GHz-slot-width LSP request arrives, the actual slot width assigned to 
this LSP may be 100GHz. So such fields in traffic parameters cannot 
exclude the use of "m" in the label, from signaling perspective.

I also notice that Fatai oppose the use of "m" in label from routing 
perspective. In [draft-wangl-ccamp-ospf-ext-constraint-flexi-grid-01], for 
the label set with type 2/3 inclusive/exclusive range, "The value of m in 
start/end label is meaningless", and "32 additional bits space is used to 
carry meaningless information!  People can image how many labels are 
distributed in the routing. What scalable issue it is!" In my opinion, 
this document is only an individual draft to summarize our idea and 
initial work on OSPF extension of Flexible-Grid networks,and needs further 
modification and extension according to the requirements and feedback of 
others. Thanks for pointing out the improper place. However, in this 
document, the type 2/3 inclusive/exclusive range can be well replaced by 
the type 0/1 inclusive/exclusive label list, without any bit-wasting. In 
addition, there is not any mandatory requirement that the start/end label 
in label set MUST keep the same format with the label in signaling, so I 
think the meaningless part could be simply removed in the label set, both 
type 2/3 and type 4. Above all, it is not a serious problem that cannot 
conquered, and has no impact on the use of "m" in the label, from routing 
perspective.

The second one, I partly agree with Adrian. "For me, the most basic 
building block is the label. Next would come the signaling parameters." 
that is right. but I also agree with Iftekhar that "Certainly, label 
definition for flex-grid is a very important component, this does not mean 
the other aspects including routing and signaling extensions are any less 
important. I think rather than taking a piecemeal approach we should look 
at a system approach." that is why I submit the draft 
[draft-wangl-ccamp-ospf-ext-constraint-flexi-grid-01]. Maybe beyond 100G 
is still premature until now, but the study of control pane must keep pace 
with advanced research and technology. Is it a little late to initiate 
this work after the deployment of beyond 100G? 

I have proposed some ideas on routing protocol extesions in 
[draft-wangl-ccamp-ospf-ext-constraint-flexi-grid-01], including label 
set, Flexible-Grid ability (grid type, slot width granularity and Min/Max 
slot width) and optical signal compatibility information, which coud be 
flooded by OSPF for efficient RSA. it is just an initial work and needs 
further study on this topic, however, I am glad to see that Fatai 
acknowledged and added these ideas to his draft on framework and routing 
extensions several days after my submission. Further discussion is 
welcome. 

By the way, in my opinion, split-spectrum super channel is an interesting 
idea in flexible-grid networks, and I also notice that some advance 
research and technology presented in OFC/ECOC indeed support such super 
channel. I am glad to see further study on this topic, and 
cost/efficiency/benefits comparison between contiguous super channel and 
split-spectrum super channel. Of course, it is out the scope of IETF :-) 

Best Regards

Lei Wang 

--------------------------------------------
LeiWang

ZTE
Bearer Network Product Pre_research Department,
Wireline R&D Insititute
Cell phone:+86 13811440067
Email: [email-masked]
       [email-masked]
       [email-masked]
----------------------------------------------

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 22 Mar 2012 10:48:09 +0000

Hi Lei,

Please see my comments in-line.

Thanks

Fatai

From: [email-masked] [mailto:[email-masked]]
Sent: 2012年3月22日 17:27
To: [email-masked]; [email-masked]; Fatai Zhang; [email-masked]
Subject: Re: [CCAMP] Update to draft-farrkingel-ccamp-flexigrid-lambda-label

It seems that flexible-grid network is becoming a hot topic in these days, but I also find that the discussions mainly focus on two problems listed as follows:

2. What should we discuss in the first step, the whole Flexible-Grid control plane or just label and signaling parameters?

The first one, I absolutely agree with Adrian. "the view that "m" is part of the definition of what is being switched and is essential for the switch cross-connect to be programmed. Thus,it is part of the label." "I would acknowledge that the value of "m" influences the bandwidth of the LSP, but I would claim that an Path request asks for b/w in the traffic parameters and the label returned provides the value of "m" to be programmed into the XC. If it is necessary (perhaps a question fordraft-zhang-ccamp-flexible-grid-rsvp-te-ext) to also specify "m" (or a range of acceptable values of "m") as part of the Path request, then it would seem pragmatic to put it in the traffic parameters."

In my opinion, it may be reasonable to carry certain fields in traffic parameters that claim min slot width or slot width range the LSP requests, as well, it is also necessary to include "m" in the label to claim actual slot width assigned to this LSP. For example, assuming a flexible-grid network composed of optical components with 25GHz slot width granularity and [50GHz, 200GHz] slot width range. When a 25GHz-slot-width LSP request arrives, the signaling may add 25GHz in traffic parameters to claim the min slot width required. However, due to the Flexible-Grid capability limitation of optical components, the actual slot width assigned to this LSP may be 50GHz, which is added as "m" in the label. similarly, When a 87.5GHz-slot-width LSP request arrives, the actual slot width assigned to this LSP may be 100GHz. So such fields in traffic parameters cannot exclude the use of "m" in the label, from signaling perspective.

[Fatai] Are you kidding? When 25GHz is requested, but 50GHz is allocated finally? In this case, this request should be rejected. Secondly, why routing cannot be aware of this constraint? I think this constraint should be advertised into routing and then the head node or PCE can calculate the exact bandwidth needed before signaling.

I also notice that Fatai oppose the use of "m" in label from routing perspective. In [draft-wangl-ccamp-ospf-ext-constraint-flexi-grid-01], for the label set with type 2/3 inclusive/exclusive range, "The value of m in start/end label is meaningless", and "32 additional bits space is used to carry meaningless information!  People can image how many labels are distributed in the routing. What scalable issue it is!" In my opinion, this document is only an individual draft to summarize our idea and initial work on OSPF extension of Flexible-Grid networks,and needs further modification and extension according to the requirements and feedback of others. Thanks for pointing out the improper place. However, in this document, the type 2/3 inclusive/exclusive range can be well replaced by the type 0/1 inclusive/exclusive label list, without any bit-wasting. In addition, there is not any mandatory requirement that the start/end label in label set MUST keep the same format with the label in signaling, so I think the meaningless part could be simply removed in the label set, both type 2/3 and type 4. Above all, it is not a serious problem that cannot conquered, and has no impact on the use of "m" in the label, from routing perspective.

[Fatai]  Many big issues if ‘m’ is used in the routing.

Per G.694.1, slot width is only significant for a frequency slot (ie., a specific connection). There is no pre-defined fixed “wavelength” for the link resource of flexi-grid, because it is flexible (ie., the slot width is uncertain before a frequency slot is allocated), so there is no need to advertise slot width (or ‘m’). This is the reason to have meaningless ‘m’ in your draft.

Even though type 0/1 is used, there is still big issue. For example, if the available spectrum is odd times of  the central frequency granularity (5*6.25GHz), how to encode the value of ‘m’? are you trying to use m=2.5?

If  a label format in routing is different from in signaling as you said, I would like to see the label format.

The second one, I partly agree with Adrian. "For me, the most basic building block is the label. Next would come the signaling parameters." that is right. but I also agree with Iftekhar that "Certainly, label definition for flex-grid is a very important component, this does not mean the other aspects including routing and signaling extensions are any less important. I think rather than taking a piecemeal approach we should look at a system approach." that is why I submit the draft [draft-wangl-ccamp-ospf-ext-constraint-flexi-grid-01]. Maybe beyond 100G is still premature until now, but the study of control pane must keep pace with advanced research and technology. Is it a little late to initiate this work after the deployment of beyond 100G?

I have proposed some ideas on routing protocol extesions in [draft-wangl-ccamp-ospf-ext-constraint-flexi-grid-01], including label set, Flexible-Grid ability (grid type, slot width granularity and Min/Max slot width) and optical signal compatibility information, which coud be flooded by OSPF for efficient RSA. it is just an initial work and needs further study on this topic, however, I am glad to see that Fatai acknowledged and added these ideas to his draft on framework and routing extensions several days after my submission. Further discussion is welcome.

[Fatai] Let’s discuss more to get the feasible solution for the industry. Happy to discuss more with you.

By the way, in my opinion, split-spectrum super channel is an interesting idea in flexible-grid networks, and I also notice that some advance research and technology presented in OFC/ECOC indeed support such super channel. I am glad to see further study on this topic, and cost/efficiency/benefits comparison between contiguous super channel and split-spectrum super channel. Of course, it is out the scope of IETF :-)

[Fatai] Agree with you.

Best Regards

Lei Wang

ZTE

---

From: [email-masked]
Date: Thu, 22 Mar 2012 20:06:30 +0800

Hi, Fatai,

By the way, I am sorry for the "security notice" message automatically 
dilivered by our system, but I have no way to delete it. 

thanks!

Lei Wang 

Fatai Zhang <[email-masked]> 
2012-03-22 18:48

收件人
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>, 
"[email-masked]" <[email-masked]>
抄送

主题
RE: [CCAMP] Update to draft-farrkingel-ccamp-flexigrid-lambda-label

Hi Lei,

Thanks
 
Fatai
 
From: [email-masked] [mailto:[email-masked]] 
Sent: 2012年3月22日 17:27
To: [email-masked]; [email-masked]; Fatai Zhang; 
[email-masked]
Subject: Re: [CCAMP] Update to 
draft-farrkingel-ccamp-flexigrid-lambda-label

 
[Fatai] Are you kidding? When 25GHz is requested, but 50GHz is allocated 
finally? In this case, this request should be rejected. Secondly, why 
routing cannot be aware of this constraint? I think this constraint should 
be advertised into routing and then the head node or PCE can calculate the 
exact bandwidth needed before signaling.

[Lei] That is just an example. let us dicuss it in detail. in my opinion, 
the idea mentioned above is extremely useful for Flexible-Grid networks 
with various flexible-grid ability components. Assuming a network composed 
of two kinds optical components: 1. 25GHz slot width granularity and 
[50GHz, 300GHz] slot width range; 2. 12.5GHz slot width granularity and 
[50GHz, 200GHz] slot width range. Just as Figure 1 in 
[draft-wangl-ccamp-ospf-ext-constraint-flexi-grid-01].
 
                 +----+A-E2    B-I1+----+B-E2    C-I1+----+
                 | A  |----------->| B  |----------->| C  |
                 |    |<-----------|    |<-----------|    |
                 +----+A-I2    B-E1+----+B-I2    C-E1+----+
                   O|                O|                O|
               A-I1||A-E1        B-I3||B-E3        C-I2||C-E2
                   ||                ||                ||
                   ||                ||                ||
                   ||                ||                ||
                   ||                ||                ||
               D-E1||D-I1        E-E3||E-I3        F-E2||F-I2
                   |O                |O                |O
                 +----+D-E2    E-I1+----+E-E2    F-I1+----+
                 | D  |----------->| E  |----------->| F  |
                 |    |<-----------|    |<-----------|    |
                 +----+D-I2    E-E1+----+E-I2    F-E1+----+

     Figure 1. A sample network with both Fixed-Grid and Flexible-Grid
                                 elements

       +----+---------+-----+------+-----------+---------+---------+
       |Node|Node-Type|Ports| Type |Granularity|Min width|Max width|
       +----+---------+-----+------+-----------+---------+---------+
       |    |         |A-E1 | Flex |    25GHz  |  50GHz  | 300GHz  |
       | A  |  Flex   |-----+------+-----------+---------+---------+
       |    |         |A-E2 | Flex |  12.5GHz  |  50GHz  | 200GHz  |
       +----+---------+-----+------+-----------+---------+---------+
       |    |         |B-E1 | Flex |  12.5GHz  |  50GHz  | 200GHz  |
       |    |         |-----+------+-----------+---------+---------+
       | B  |  Mixed  |B-E2 | Fixed|    50GHz  |  50GHz  |  50GHz  |
       |    |         |-----+------+-----------+---------+---------+
       |    |         |B-E3 | Flex |  12.5GHz  |  50GHz  | 200GHz  |
       +----+---------+-----+------+-----------+---------+---------+
       |    |         |C-E1 | Fixed|    50GHz  |  50GHz  |  50GHz  |
       | C  |  Fixed  |-----+------+-----------+---------+---------+
       |    |         |C-E2 | Fixed|    50GHz  |  50GHz  |  50GHz  |
       +----+---------+-----+------+-----------+---------+---------+
       |    |         |D-E1 | Flex |    25GHz  |  50GHz  | 300GHz  |
       | D  |  Flex   |-----+------+-----------+---------+---------+
       |    |         |D-E2 | Flex |    25GHz  |  50GHz  | 300GHz  |
       +----+---------+-----+------+-----------+---------+---------+
       |    |         |E-E1 | Flex |    25GHz  |  50GHz  | 300GHz  |
       |    |         |-----+------+-----------+---------+---------+
       | E  |  Flex   |E-E2 | Flex |  12.5Ghz  |  50GHz  | 200GHz  |
       |    |         |-----+------+-----------+---------+---------+
       |    |         |E-E3 | Flex |  12.5GHz  |  50GHz  | 200GHz  |
       +----+---------+-----+------+-----------+---------+---------+
       |    |         |F-E1 | Flex |  12.5GHz  |  50GHz  | 200GHz  |
       | F  |  Mixed  |-----+------+-----------+---------+---------+
       |    |         |F-E2 | Fixed|    50GHz  |  50GHz  |  50GHz  |
       +----+---------+-----+------+-----------+---------+---------+

When a 87.5GHz-slot-width A->E LSP request arrives, assuming there is not 
any available spectrum resource on route A-B-E, A-D-E is selected as the 
LSP route and 100GHz slot width is assigned. what you mean is that the 
computation elements should get information of flexible-grid ability of 
each optical components by OSPF flooding, so the header can calculate the 
actual slot width without carring 87.5GHz in traffic parameters, Do I 
understand right? OK, there is a big problem, ausuming fiber AD breaks 
down and LSP reroute reuests, and then route A-B-E is selected, how many 
slot widths would asssigned to that LSP? also 100GHz? It is not resonable 
because 87.5GHz is enough. but how could the control plane get this 
information? In my opinion, from traffic parameters. 

Would you agree with me?

 
Per G.694.1, slot width is only significant for a frequency slot (ie., a 
specific connection). There is no pre-defined fixed “wavelength” for the 
link resource of flexi-grid, because it is flexible (ie., the slot width 
is uncertain before a frequency slot is allocated), so there is no need to 
advertise slot width (or ‘m’). This is the reason to have meaningless ‘
m’ in your draft. 
 
Even though type 0/1 is used, there is still big issue. For example, if 
the available spectrum is odd times of  the central frequency granularity 
(5*6.25GHz), how to encode the value of ‘m’? are you trying to use 
m=2.5?
 
If  a label format in routing is different from in signaling as you said, 
I would like to see the label format.

[Lei] I agree with you that in both type 2/3 and type4 "m" is meaningless, 
and I also illustrate it in my draft. My idea is that, "there is not any 
mandatory requirement that the start/end label in label set MUST keep the 
same format with the label in signaling, so I think the meaningless part 
could be simply removed in the label set, both type 2/3 and type 4." Is it 
not clear? 

 "if the available spectrum is odd times of  the central frequency 
granularity (5*6.25GHz), how to encode the value of ‘m’?" Firstly, it is 
impossible that the available spectrum is odd times of  the central 
frequency granularity, at least for recent optical components. please see 
the reference: "Dynamic wavelength processor WSS with FLEXGRID 
functionality [Finisar]"; Secondly ,event if it is possible, type 2/3 and 
type 4 could well express that, Would you agree with me?

In my opinion, the problem mentioned above has no relations to the use of 
"m" in label, I am confused that why you oppose the label format with "m" 
from this point?

 
[Fatai] Let’s discuss more to get the feasible solution for the industry. 
Happy to discuss more with you.

[Lei] I am also glad to discuss with you.

[Fatai] Agree with you.

[Lei] By the way, is there any simulation or test results to show 
cost/efficiency/benefits comparison between contiguous super channel and 
split-spectrum super channel? thank you!! :-)

Best Regards 

Lei Wang 

ZTE
 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 23 Mar 2012 03:48:15 +0000

Hi Lei,

<Snip>

[Lei] That is just an example. let us dicuss it in detail. in my opinion, the idea mentioned above is extremely useful for Flexible-Grid networks with various flexible-grid ability components. Assuming a network composed of two kinds optical components: 1. 25GHz slot width granularity and [50GHz, 300GHz] slot width range; 2. 12.5GHz slot width granularity and [50GHz, 200GHz] slot width range. Just as Figure 1 in [draft-wangl-ccamp-ospf-ext-constraint-flexi-grid-01].

When a 87.5GHz-slot-width A->E LSP request arrives, assuming there is not any available spectrum resource on route A-B-E, A-D-E is selected as the LSP route and 100GHz slot width is assigned. what you mean is that the computation elements should get information of flexible-grid ability of each optical components by OSPF flooding, so the header can calculate the actual slot width without carring 87.5GHz in traffic parameters, Do I understand right? OK, there is a big problem, ausuming fiber AD breaks down and LSP reroute reuests, and then route A-B-E is selected, how many slot widths would asssigned to that LSP? also 100GHz? It is not resonable because 87.5GHz is enough. but how could the control plane get this information? In my opinion, from traffic parameters.

[Fatai]  Certainly, 87.5GHZ can be requested for the recovery LSP and m=7 should be carried in the traffic parameters. This is what I am proposing.

Would you agree with me?

[Fatai]  Many big issues if 'm' is used in the routing.

Per G.694.1, slot width is only significant for a frequency slot (ie., a specific connection). There is no pre-defined fixed "wavelength" for the link resource of flexi-grid, because it is flexible (ie., the slot width is uncertain before a frequency slot is allocated), so there is no need to advertise slot width (or 'm'). This is the reason to have meaningless 'm' in your draft.

Even though type 0/1 is used, there is still big issue. For example, if the available spectrum is odd times of  the central frequency granularity (5*6.25GHz), how to encode the value of 'm'? are you trying to use m=2.5?

[Lei] I agree with you that in both type 2/3 and type4 "m" is meaningless, and I also illustrate it in my draft. My idea is that, "there is not any mandatory requirement that the start/end label in label set MUST keep the same format with the label in signaling, so I think the meaningless part could be simply removed in the label set, both type 2/3 and type 4." Is it not clear?

[Fatai]  Clear now. Happy to see that you agree 'm' should be removed in the label.

 "if the available spectrum is odd times of  the central frequency granularity (5*6.25GHz), how to encode the value of 'm'?" Firstly, it is impossible that the available spectrum is odd times of  the central frequency granularity, at least for recent optical components. please see the reference: "Dynamic wavelength processor WSS with FLEXGRID functionality [Finisar]"; Secondly ,event if it is possible, type 2/3 and type 4 could well express that, Would you agree with me?

[Fatai]  Why it is impossible? This case should be very common.
Please see the Figure I.1 in G.694.1 copied as follows. In this example, the available spectrum is 9*6.25GHz. Therefore, the label format with 'm' cannot handle this common case.

In my opinion, the problem mentioned above has no relations to the use of "m" in label, I am confused that why you oppose the label format with "m" from this point?

[Fatai]  As explained above. It is related to the usage of 'm' in your draft. I am trying to make people understand 'm' should not be carried in the routing (and so in the label). I will continue to make this effort until people understand this point.

Best Regards

Lei Wang

ZTE

---

From: [email-masked]
Date: Fri, 23 Mar 2012 13:12:11 +0800

Hi Fatai,

thanks!

Lei Wang

Hi Lei, 
 
<Snip>

  

 
[Fatai]  Certainly, 87.5GHZ can be requested for the recovery LSP and m=7 
should be carried in the traffic parameters. This is what I am proposing.

[Lei] Would my expression be not clear? My idea is that: in such 
condition, 87.5GHz could be carried by traffic parameters in signaling to 
claim the minimum slot width required by this LSP, but the actual slot 
width assigned to it MUST be carried by label, in the case mentioned 
above, "m" is set to 100GHz when setup but 87.5GHz when reroute.

In addition, the problem "how many slot widths should be assigned to a 
LSP" is very complex, it is impacted by signal attribution, accumulated 
physical impairments (both static and dynamic), filter cascading effects 
and so on, and also interact with neighbor channels. it seems impossible 
for the head to determine all of these at the beginning of path setup due 
to incomplete or dated information.

Furthermore, Just as specified in your framework draft, it supports the 
Routing + Distributed Spectrum Assignment (R+DSA) architecture. If I 
understand right, the end node determines the spectrum assigned to the LSP 
in DSA, so how could the head know how many slot width shoud be assigned?

Would you agree with me? 

  

[Fatai]  Clear now. Happy to see that you agree ‘m’ should be removed in 
the label.

[Lei] My idea is that: 1. for both type 2/3 and type 4, remove "m" in 
start/end label of label set according to the requirements; 2. there is 
not any mandatory requirement that the start/end label in label set MUST 
keep the same format with the label in signaling, and I also support that 
the use of "m" in flexible-grid label in signaling. 

[Fatai]  Why it is impossible? This case should be very common. 
Please see the Figure I.1 in G.694.1 copied as follows. In this example, 
the available spectrum is 9*6.25GHz. Therefore, the label format with ‘m
’ cannot handle this common case.

[Lei] I say that from the point of optical components, recent industry 
products such as Flexible-Grid WSS cannot support the condition mentioned 
above. "event if it is possible, type 2/3 and type 4 could well express 
it"

[Fatai]  As explained above. It is related to the usage of ‘m’ in your 
draft. I am trying to make people understand ‘m’ should not be carried 
in the routing (and so in the label). I will continue to make this effort 
until people understand this point.

 [Lei] In my opinion, there is no conflict between ‘m’ should not be 
carried in type 2/3/4 label set and  the usage of ‘m’ in label.

Best Regards 

Lei Wang

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 23 Mar 2012 07:16:55 +0000

Hi Lei,

I think we should discuss more f2f at Paris, :)

If my following understanding is correct, I think you are trying to use a label format without 'm' field in the routing, which is different from the label format (with 'm') in the signaling.

Based on this purpose, it seems that two kinds of label formats should be needed.

Please see more in black font inline.

<Snip>

[Lei]....

[Lei] Would my expression be not clear? My idea is that: in such condition, 87.5GHz could be carried by traffic parameters in signaling to claim the minimum slot width required by this LSP, but the actual slot width assigned to it MUST be carried by label, in the case mentioned above, "m" is set to 100GHz when setup but 87.5GHz when reroute.
[Fatai]  Point 1: Are you trying to break the rule of GMPLS for optical by saying "the minimum slot width required by this LSP, but the actual slot width assigned to it MUST be carried by label"? Please remember that flexi-grid is not packet network. If you want to do that, I think you can create a new thread for discussion.
[Fatai]  Point 2: You said "in the case mentioned above, "m" is set to 100GHz when setup but 87.5GHz when reroute."  I think your example is very special. Even for this special case, I think the simple way is to set 'm'=100GHz in the traffic parameters when setup (A-D-E) and 'm'=87.5GHz in the traffic parameters to create the recovery LSP (A-B-E). No need to insert minimum slot width in the traffic parameters. Please don't mix two LSPs together because traffic parameters make sense for one specific LSP.
In addition, the problem "how many slot widths should be assigned to a LSP" is very complex, it is impacted by signal attribution, accumulated physical impairments (both static and dynamic), filter cascading effects and so on, and also interact with neighbor channels. it seems impossible for the head to determine all of these at the beginning of path setup due to incomplete or dated information.

Furthermore, Just as specified in your framework draft, it supports the Routing + Distributed Spectrum Assignment (R+DSA) architecture. If I understand right, the end node determines the spectrum assigned to the LSP in DSA, so how could the head know how many slot width shoud be assigned?

[Fatai] For this complex thing, from practical perspective,  the head node should get the instruction from centralized PCE or NMS. Otherwise, when you said "When a 87.5GHz-slot-width A->E LSP request", how do you know 87.5GHz should be requested?

Would you agree with me?

[Lei] My idea is that: 1. for both type 2/3 and type 4, remove "m" in start/end label of label set according to the requirements; 2. there is not any mandatory requirement that the start/end label in label set MUST keep the same format with the label in signaling, and I also support that the use of "m" in flexible-grid label in signaling.
[Fatai] I am confused now. Let me make points clear. Do you mean that you want to define two label formats? One is for routing (for type2/3/4), which does not have 'm' filed in this label. Another one is for signaling, which has 'm' filed in this label format. Is my understanding correct?
 "if the available spectrum is odd times of  the central frequency granularity (5*6.25GHz), how to encode the value of 'm'?" Firstly, it is impossible that the available spectrum is odd times of  the central frequency granularity, at least for recent optical components. please see the reference: "Dynamic wavelength processor WSS with FLEXGRID functionality [Finisar]"; Secondly ,event if it is possible, type 2/3 and type 4 could well express that, Would you agree with me?

[Lei] I say that from the point of optical components, recent industry products such as Flexible-Grid WSS cannot support the condition mentioned above. "event if it is possible, type 2/3 and type 4 could well express it"
[Fatai]  It is stated in G.694.1 clearly and it is easy for people to understand that this case can happen. OK, so you agree that type 0/1 cannot be used for this case and type 2/3/4 (without 'm') would be used?

[Lei] In my opinion, there is no conflict between 'm' should not be carried in type 2/3/4 label set and  the usage of 'm' in label.
[Fatai]  OK, I understand now that you are trying to use two different label formats. The label format in routing for type2/3/4 is different from the label format in signaling (which has 'm').

Best Regards

Lei Wang

---

From: [email-masked]
Date: Fri, 23 Mar 2012 16:28:52 +0800

Hi Fatai,

Unfortunately, My visa was rejected by France government, but you are 
welcome to discuss with my collegue Xihua Fu, Fei Zhang and Qilei Wang.

>>If my following understanding is correct, I think you are trying to use 
a label format without ‘m’ field in the routing, which is different from 
the label format (with ‘m’) in the signaling.  

[Lei] Yes, that is my point.

ZTE

Hi Lei,
 
I think we should discuss more f2f at Paris, J
 
If my following understanding is correct, I think you are trying to use a 
label format without ‘m’ field in the routing, which is different from 
the label format (with ‘m’) in the signaling. 
 
Based on this purpose, it seems that two kinds of label formats should be 
needed. 

<Snip> 

[Lei]….

[Lei] Would my expression be not clear? My idea is that: in such 
condition, 87.5GHz could be carried by traffic parameters in signaling to 
claim the minimum slot width required by this LSP, but the actual slot 
width assigned to it MUST be carried by label, in the case mentioned 
above, "m" is set to 100GHz when setup but 87.5GHz when reroute. 
[Fatai]  Point 1: Are you trying to break the rule of GMPLS for optical by 
saying “the minimum slot width required by this LSP, but the actual slot 
width assigned to it MUST be carried by label”? Please remember that 
flexi-grid is not packet network. If you want to do that, I think you can 
create a new thread for discussion. 
[Fatai]  Point 2: You said “in the case mentioned above, "m" is set to 
100GHz when setup but 87.5GHz when reroute.”  I think your example is 
very special. Even for this special case, I think the simple way is to set 
‘m’=100GHz in the traffic parameters when setup (A-D-E) and ‘m’
=87.5GHz in the traffic parameters to create the recovery LSP (A-B-E). No 
need to insert minimum slot width in the traffic parameters. Please don’t 
mix two LSPs together because traffic parameters make sense for one 
specific LSP.
In addition, the problem "how many slot widths should be assigned to a 
LSP" is very complex, it is impacted by signal attribution, accumulated 
physical impairments (both static and dynamic), filter cascading effects 
and so on, and also interact with neighbor channels. it seems impossible 
for the head to determine all of these at the beginning of path setup due 
to incomplete or dated information. 

[Fatai] For this complex thing, from practical perspective,  the head node 
should get the instruction from centralized PCE or NMS. Otherwise, when 
you said “When a 87.5GHz-slot-width A->E LSP request”, how do you know 
87.5GHz should be requested?

Would you agree with me? 

[Lei] My idea is that: 1. for both type 2/3 and type 4, remove "m" in 
start/end label of label set according to the requirements; 2. there is 
not any mandatory requirement that the start/end label in label set MUST 
keep the same format with the label in signaling, and I also support that 
the use of "m" in flexible-grid label in signaling. 
[Fatai] I am confused now. Let me make points clear. Do you mean that you 
want to define two label formats? One is for routing (for type2/3/4), 
which does not have ‘m’ filed in this label. Another one is for 
signaling, which has ‘m’ filed in this label format. Is my understanding 
correct?
 "if the available spectrum is odd times of  the central frequency 
granularity (5*6.25GHz), how to encode the value of ‘m’?" Firstly, it is 
impossible that the available spectrum is odd times of  the central 
frequency granularity, at least for recent optical components. please see 
the reference: "Dynamic wavelength processor WSS with FLEXGRID 
functionality [Finisar]"; Secondly ,event if it is possible, type 2/3 and 
type 4 could well express that, Would you agree with me? 

[Lei] I say that from the point of optical components, recent industry 
products such as Flexible-Grid WSS cannot support the condition mentioned 
above. "event if it is possible, type 2/3 and type 4 could well express 
it" 
[Fatai]  It is stated in G.694.1 clearly and it is easy for people to 
understand that this case can happen. OK, so you agree that type 0/1 
cannot be used for this case and type 2/3/4 (without ‘m’) would be used?

[Lei] In my opinion, there is no conflict between ‘m’ should not be 
carried in type 2/3/4 label set and  the usage of ‘m’ in label.
[Fatai]  OK, I understand now that you are trying to use two different 
label formats. The label format in routing for type2/3/4 is different from 
the label format in signaling (which has ‘m’).
 
Best Regards 

Lei Wang

---

From: [email-masked]
Date: Mon, 26 Mar 2012 15:34:38 +0800

Hi, Fatai,

<snip>

Please see my comments in-line:

[Qilei]: In my opinion, label format used in the routing protocol should 
be in accordance with that in the signaling in flexible grid (may be early 
to discuss the label format in the routing protocol), because consistency 
is needed.

I'm still not sure whether the scenario you introduce from ITU-T document 
is possible. Maybe we should carefully examine it or consult the author of 
the G.694.1.
The case you said is possible, to say the least of it.I think 
Inclusive/Exclusive list could also be used to represent the label range, 
as there are 24 bits reserved in the label format. We can use the reserved 
bits to indicate the offset.

Another thing: I'm confused with the use of grid type value in your draft. 
Let's see the descriptin in your draft:
"In case of Grid=1 (ITU-T DWDM), a new value of C.S. is defined for 
flexible grid. "
A new value of C.S. is defined for flexible grid. I think you mean 6.25GHz 
here. My confusion is that if the C.S. value is used for fixed grid 
purpose, how can we differentiate fixed grid from flexible grid?

I'm not sure if I miss something, please reply to me if I have wrong 
understanding here.

Thanks
Qilei

Fatai Zhang <[email-masked]> 
发件人:  [email-masked]
2012/03/23 11:48

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
Re: [CCAMP] Update to draft-farrkingel-ccamp-flexigrid-lambda-label

Hi Lei, 
 
<Snip>

  

 

Would you agree with me? 

  

 

 

Best Regards 

Lei Wang 

ZTE
Bearer Network Product Pre_research Department,
Wireline R&D Insititute
Cell phone:+86 13811440067
Email: [email-masked]
     [email-masked]
     [email-masked]
---------------------------------------------- 
 _______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 26 Mar 2012 07:56:40 +0000

Hi Qilei,

I am totally confused because what you said contradicts what your colleague (Lei Wang) said.

You like one consistent label format for both routing and signaling, but Lei supports two different label formats.

I don't know how to make this discuss move forward.

Thanks

Fatai

________________________________
发件人: [email-masked] [[email-masked]]
发送时间: 2012年3月26日 15:34
到: Fatai Zhang
Cc: [email-masked]
主题: Re: Re: [CCAMP] Update to draft-farrkingel-ccamp-flexigrid-lambda-label

Hi, Fatai,

<snip>

"if the available spectrum is odd times of  the central frequency granularity (5*6.25GHz), how to encode the value of ‘m’?" Firstly, it is impossible that the available spectrum is odd times of  the central frequency granularity, at least for recent optical components. please see the reference: "Dynamic wavelength processor WSS with FLEXGRID functionality [Finisar]"; Secondly ,event if it is possible, type 2/3 and type 4 could well express that, Would you agree with me?

[Fatai]  Why it is impossible? This case should be very common.
Please see the Figure I.1 in G.694.1 copied as follows. In this example, the available spectrum is 9*6.25GHz. Therefore, the label format with ‘m’ cannot handle this common case.

[Qilei]: In my opinion, label format used in the routing protocol should be in accordance with that in the signaling in flexible grid (may be early to discuss the label format in the routing protocol), because consistency is needed.

I'm still not sure whether the scenario you introduce from ITU-T document is possible. Maybe we should carefully examine it or consult the author of the G.694.1.
The case you said is possible, to say the least of it.I think Inclusive/Exclusive list could also be used to represent the label range, as there are 24 bits reserved in the label format. We can use the reserved bits to indicate the offset.

Another thing: I'm confused with the use of grid type value in your draft. Let's see the descriptin in your draft:
"In case of Grid=1 (ITU-T DWDM), a new value of C.S. is defined for flexible grid. "
A new value of C.S. is defined for flexible grid. I think you mean 6.25GHz here. My confusion is that if the C.S. value is used for fixed grid purpose, how can we differentiate fixed grid from flexible grid?

I'm not sure if I miss something, please reply to me if I have wrong understanding here.

Thanks
Qilei

2012/03/23 11:48

收件人
        "[email-masked]" <[email-masked]>
抄送
        "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
主题
        Re: [CCAMP] Update to draft-farrkingel-ccamp-flexigrid-lambda-label

Hi Lei,

<Snip>

Would you agree with me?

[Fatai]  Clear now. Happy to see that you agree ‘m’ should be removed in the label.

 "if the available spectrum is odd times of  the central frequency granularity (5*6.25GHz), how to encode the value of ‘m’?" Firstly, it is impossible that the available spectrum is odd times of  the central frequency granularity, at least for recent optical components. please see the reference: "Dynamic wavelength processor WSS with FLEXGRID functionality [Finisar]"; Secondly ,event if it is possible, type 2/3 and type 4 could well express that, Would you agree with me?

[Fatai]  Why it is impossible? This case should be very common.
Please see the Figure I.1 in G.694.1 copied as follows. In this example, the available spectrum is 9*6.25GHz. Therefore, the label format with ‘m’ cannot handle this common case.

[Fatai]  As explained above. It is related to the usage of ‘m’ in your draft. I am trying to make people understand ‘m’ should not be carried in the routing (and so in the label). I will continue to make this effort until people understand this point.

Best Regards

Lei Wang

ZTE

---

From: [email-masked]
Date: Mon, 26 Mar 2012 16:15:06 +0800

Hi, Fatai,

Just focus on the technical point. My purpose is to make the work forward.

Maybe your solution, our solution or others will eventually become the 
best choice. So let's discuss the case that I raised in the previous 
email.

Thanks
Qilei

2012/03/26 15:56

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
答复: Re: [CCAMP] Update to draft-farrkingel-ccamp-flexigrid-lambda-label

Hi Qilei,

I am totally confused because what you said contradicts what your 
colleague (Lei Wang) said.

You like one consistent label format for both routing and signaling, but 
Lei supports two different label formats.

Thanks

Fatai

发件人: [email-masked] [[email-masked]]
发送时间: 2012年3月26日 15:34
到: Fatai Zhang
Cc: [email-masked]
主题: Re: Re: [CCAMP] Update to 
draft-farrkingel-ccamp-flexigrid-lambda-label

Hi, Fatai, 

<snip> 

Thanks 
Qilei 

收件人

Hi Lei, 
  
<Snip> 

 

  

Would you agree with me? 

 

  

  

Best Regards 

Lei Wang 

ZTE

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 26 Mar 2012 08:32:03 +0000

Hi Qilei,

Does what I said not touch the tech  points?  I think we can discuss more f2f.

I have spent so much time on making Lei understand that 'm' should not advertised in the routing, and he finally agreed on what I explained.

I know that you like one consistent label format, so do you mean that 'm' should still used in the label as described in  Lei's routing draft? What is your consistent label format?

For your question on 6.25GHz CS for fixed grid, we all know that there is no this kind of CS for fixed grid. IETF control plane must follow the standardized recommendation of ITU-T data plane.

Thanks

Fatai

发送时间: 2012年3月26日 16:15

Hi, Fatai,

Maybe your solution, our solution or others will eventually become the best choice. So let's discuss the case that I raised in the previous email.

Thanks
Qilei

2012/03/26 15:56

收件人

Hi Qilei,

Thanks

Fatai

Hi, Fatai,

<snip>

Thanks
Qilei

2012/03/23 11:48

收件人

Hi Lei,

<Snip>

Would you agree with me?

Best Regards

Lei Wang

ZTE