Re: [CCAMP] 答复: POLLING - draft-ietf-ccamp-flexible-grid-ospf-ext-02 - Encoding Options

["Zhangxian (Xian)" <[e-mail]>]

Hi, Gabriele,

   Thank you for your further explanation. I get your point now.

   I think what you said below is already supported by RFC6205 and the flexi-grid label draft, since RFC6205 states:

+----------+---------+
   |C.S. (GHz)|  Value  |
   +----------+---------+
   | Reserved |    0    |
   +----------+---------+
   |    100   |    1    |
   +----------+---------+
   |    50    |    2    |
   +----------+---------+
   |    25    |    3    |
   +----------+---------+
   |    12.5  |    4    |
   +----------+---------+
   |Future use|  5 - 15 |
   +----------+---------+


We added 5 as 6.25 in [draft-ietf-ccamp-flexigrid-lambda-label<https://tools.ietf.org/html/draft-ietf-ccamp-flexigrid-lambda-label-04.txt>], which means naturally that 6-15 are for future use and subject to, as you said, the evolution of technologies.



My understanding is we do not need to add anything in OSPF draft to support this. Is it correct?



Regards,
Xian



From: Gabriele Maria Galimberti (ggalimbe) [mailto:[e-mail]]
Sent: 2015年8月20日 15:24
To: Zhangxian (Xian); Daniele Ceccarelli; CCAMP ([e-mail])
Cc: Zhenghaomian
Subject: Re: [CCAMP] 答复: POLLING - draft-ietf-ccamp-flexible-grid-ospf-ext-02 - Encoding Options

Hi Xian,

I'm OK with the definition of CFG and SWG as a multiple of Minimum Granularity (today 6.25 and 12.5 as per G.694.1).
My suggestion is to make the Minimum Granularity a variable so that can be changed in future
And assign the values 5 and 4  as indicated by RFC 6205 and

draft-ietf-ccamp-flexigrid-lambda-label<https://tools.ietf.org/html/draft-ietf-ccamp-flexigrid-lambda-label-04.txt>


   +----------+---------+

   |C.S. (GHz)|  Value  |

   +----------+---------+

   | Reserved |    0    |

   +----------+---------+

   |    100   |    1    |

   +----------+---------+

   |    50    |    2    |

   +----------+---------+

   |    25    |    3    |

   +----------+---------+

   |    12.5  |    4    |

   +----------+---------+

   |     6.25 |    5    |

   +----------+---------+

   |Future use|  6 - 15 |

   +----------+---------+


The above table (I modified from 6205) is subject to evolve with the evolution of

The technology (there might be values 6 or more) but the signalling

Will not change.


Best Regards,


Gabriele
[http://www.cisco.com/swa/i/logo.gif]


Gabriele Galimberti
Principal Engineer
Cisco Photonics Srl


via S.Maria Molgora, 48 C
20871 - Vimercate (MB)
Italy
www.cisco.com/global/IT/<http://www.cisco.com/global/IT/>

[e-mail]<mailto:[e-mail]>
Phone :[phone]
Mobile :[phone]
Fax :[phone]











Assign the

From: Xian Zhang <[e-mail]<mailto:[e-mail]>>
Date: Thursday, August 20, 2015 4:01 AM
To: Daniele Ceccarelli <[e-mail]<mailto:[e-mail]>>, Gabriele Galimberti <[e-mail]<mailto:[e-mail]>>, "CCAMP ([e-mail]<mailto:[e-mail]>)" <[e-mail]<mailto:[e-mail]>>
Cc: Zhenghaomian <[e-mail]<mailto:[e-mail]>>
Subject: RE: [CCAMP] 答复: POLLING - draft-ietf-ccamp-flexible-grid-ospf-ext-02 - Encoding Options

Hi, Gabriele and Daniele,

   I am not sure I get the 2nd point that needs to be updated.

Currently, the two values (i.e., CFG and SWG) is used to convey the limitation of a node.  This is because a node may not support the granularity of 6.25G(CS) and 12.5 (SW) as currently defined by G.694.1 and it might support only larger numbers (for example, 12.5 and 25, so CFG will be set to 2 and SWG=2).  This is aligned with what is currently defined in the label draft where we have a new 6.25 CS value.

So, Gabriele, could you please explain further what is the further proofness you meant for the routing draft only? And what changes you would like to see in the draft?

Regards,
Xian

From: CCAMP [mailto:[e-mail]] On Behalf Of Daniele Ceccarelli
Sent: 2015年8月19日 20:30
To: Gabriele Maria Galimberti (ggalimbe); Zhenghaomian; CCAMP ([e-mail]<mailto:[e-mail]>)
Subject: Re: [CCAMP] 答复: POLLING - draft-ietf-ccamp-flexible-grid-ospf-ext-02 - Encoding Options

Thanks Gabriele and all for your replies.

It seems that the consensus is leaning toward solution c) only (i.e. Bitmap label set).
If we need to diverge from what we did for WSON (i.e. a+b+c) I’m in favor of a solution with a single option.

I would suggest changing the draft accordingly and adding the two modifications requested from Ramon/Sergio and Gabriele, namely:


1.      Clarification on the usage of the bitmap

2.      Change Central Frequency granularity and Slot width granularity to variable fields for futureproofness.

Thanks
Daniele


From: Gabriele Maria Galimberti (ggalimbe) [mailto:[e-mail]]
Sent: martedì 18 agosto 2015 15:48
To: Zhenghaomian; Daniele Ceccarelli; CCAMP ([e-mail]<mailto:[e-mail]>)
Subject: Re: [CCAMP] 答复: POLLING - draft-ietf-ccamp-flexible-grid-ospf-ext-02 - Encoding Options

Hi WG,

I'd vote for solution C.

But looking at the doc. I see that the Central Frequency Granularity (6.25GHz) and the Slot Width Granularity (12.5GHz)
Are fixed values.  My suggestion is to make them variable because sooner or later the technology will evolve and
Those values will change for sure.

Best Regards,

Gabriele
[http://www.cisco.com/swa/i/logo.gif]


Gabriele Galimberti
Principal Engineer
Cisco Photonics Srl


via S.Maria Molgora, 48 C
20871 - Vimercate (MB)
Italy
www.cisco.com/global/IT/<http://www.cisco.com/global/IT/>

[e-mail]<mailto:[e-mail]>
Phone :[phone]
Mobile :[phone]
Fax :[phone]












From: CCAMP <[e-mail]<mailto:[e-mail]>> on behalf of Zhenghaomian <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, August 11, 2015 11:34 AM
To: Daniele Ceccarelli <[e-mail]<mailto:[e-mail]>>, "CCAMP ([e-mail]<mailto:[e-mail]>)" <[e-mail]<mailto:[e-mail]>>
Subject: [CCAMP] 答复: POLLING - draft-ietf-ccamp-flexible-grid-ospf-ext-02 - Encoding Options

Hi, Daniele and CCAMPers,

As an author, I would like to keep the draft as it is, or alternatively speaking, keep it consistent with [RFC7579] (previous [GEN-ENCODE]) for label set field description, even if this is a new defined TLV.

I am interested in, if any implementation already support 3 methods as defined in [RFC7579], how much additional effort is needed to support 3 methods in this draft? If not much, I suggest we keep them all.

There won’t be inter-op problem as long as standardized.

Best wishes,
Haomian

发件人: CCAMP [mailto:[e-mail]] 代表 Daniele Ceccarelli
发送时间: 2015年7月27日 17:14
收件人: CCAMP ([e-mail]<mailto:[e-mail]>)
主题: [CCAMP] POLLING - draft-ietf-ccamp-flexible-grid-ospf-ext-02 - Encoding Options

Working group,

at the meeting in Prague we received a comment on the high number of existing options for “available resources” encoding in OSPF for flexi-grid.
The draft actually supports (in line with the WSON encoding) three methods:


a)      Inclusive/Exclusive label ranges

b)      Inclusive/Exclusive label Lists

c)      Bitmap label set

What we’d like to hear from the working group is if the worry for too many alternatives is shared and, if so, which ones are the preferred.
Please choose one of the following options and say why:

Option 1: a) only
Option 2: b) only
Option 3: c) only
Option 4: a)+b)+c) (i.e. keep the draft as it is)
Option 5: any combination of a),b),c). If you choose 5 please say which options you want to keep and which ones to drop.

Thanks,
Daniele