Subject: Re: [CCAMP] simplified 'when' was Re: WG last call on draft-ietf-ccamp-flexigrid-yang-11

From: tom petch <[email-masked]>
Date: Sat, 1 Jan 2022 11:50:03 +0000

From: CCAMP <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 31 December 2021 10:22
From: CCAMP <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 30 December 2021 11:02
From: CCAMP <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 20 December 2021 11:03
From: CCAMP <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 20 December 2021 10:20
From: CCAMP <[email-masked]> on behalf of Daniele Ceccarelli <daniele.ceccarelli=[email-masked]>
Sent: 17 December 2021 14:50

<snipping slightly>

CCAMP,

This starts a 4 weeks working group last call on draft-ietf-ccamp-flexigrid-yang-11
The last call ends on Friday January 14th. Please send you comments to the CCAMP mailing list.

<tp3>

Also on 'when' the tests are all the same except that they are not because they use a relative path statement so they are all different.  If the 'when' used an absolute form then they would all be identical and it would be obvious whether they were right or wrong.  Thoughts?

<tp3>

I asked on the netmod list and my first idea was wrong because there is a list in the XPath which would then be true if any network had the flexigrid type so the augments would be for every node not just the flexigrid ones.

However, there is an 'ancestor' function which  would seem to overcome this.

<tp4>

The discussion on the netmod list is ongoing and the XPath ancestor: function is not an exact match for the relative XPath in use at present since it looks for a match in any ancestor node and not just the wanted one but is simpler, harder to get wrong and seems to me like an improvement.

I will continue to keep you posted

Tom Petch

<tp>
<snip>

---

From: Italo Busi <[email-masked]>
Date: Wed, 5 Jan 2022 16:55:02 +0000

CCAMP,

As contributor I support the publication of this draft after having addressed the WG LC comments

I have just noted that the intended status of this draft should be Standard Track rather than Informational: I think this could be fixed in the next revision addressing the WG LC comments

I take the opportunity to wish you an Happy New Year

Thanks, Italo

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: venerdì 17 dicembre 2021 15:50
To: CCAMP <[email-masked]>
Subject: [CCAMP] WG last call on draft-ietf-ccamp-flexigrid-yang-11

CCAMP,

the IPR declaration collection has been successfully completed and we can move to the next step. Given the upcoming holiday period we'll allow for a longer last call.

All the IPR declarations from authors and contributors have been collected and can be found in the history of the document (https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexigrid-yang/history/)
If interested, please volunteer to be the shepherd of the draft (authors excluded).

Thanks

Daniele & Fatai

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 6 Jan 2022 20:32:01 -0000

Hi Daniele and authors,

Here is my review of this draft in WG last call.

tl;dr This is ready for publication with some nits that need to be

sorted out.

Best,

Adrian

===

Throughout:

Please resolve "Flexi-Grid" or "flexi-grid"

---

As a general comment, I think it was only clear to me on reading sections

6 and 7 that this YANG module is entirely made up of individual 

augmentations of leaf nodes defined in other modules. That's not a 

problem, but it might helpful to highlight this in Section 1.

---

Section 1

   This document identifies the flexi-grid components, parameters and

   their values, characterizes the features and the performances of the

   flexi-grid elements.

I think this should be

   This document identifies the flexi-grid components, parameters, and

   their values.  It characterizes the features and the performances of

   the flexi-grid elements.

---

Section 3

   RFC Editor Note: Please replace XXXX with the RFC numbers assigned to

   [RFC9093].  Please replace YYYY with the RFC number assigned to this

   document.  Please remove this note.

I suspect that the number for XXXX is 9093 :-)

Note, however, that in Section 7 you use XXXX for this document. It may

help the RFC editor if you are consistent.

---

Section 4

OLD

      We also provide nodes A

      and B identifiers, addresses and interfaces.

NEW

      We also provide the identifiers, addresses and interfaces of nodes

      A and B.

END

s/Figure 1 shows a simple topology./Figure 2 shows a simple topology./

---

5.1

s/This document aims to describe/This document describes/

s/Traffic-engineering (TE)/traffic engineering (TE)/

s/Grid provide WDM/Grid provides WDM/

s/Traffic Engineered (TE)/TE/

s/identities and groupings/identities, and groupings/

s/The figure below/Figure 3/

s/describing an Flexi-Grid/describing a Flexi-Grid/

s/specifies with/specifies the/

---

5.1

   The Flexi-Grid specific attributes in [RFC7699], including the grid

   type, channel spacing, slot width granularity, n and m parameters,

   can be used to represent the label information.

Perhaps I am being pedantic, but isn't the label a representation of 

those parameters, not the other way round?

---

5.2.  Attributes Augmentation

   There are a few characteristics augmenting to the generic TE

   topology.

I think, probably...

5.2.  Augmentations for Flexi-Grid Topology and Node

   There are a few augmentations to the generic TE topology as described

   in this section.

---

5.2

s/topology as follows./topology as shown in Figure 4./

s/is a Flexi-Grid node/is a Flexi-Grid node as shown in Figure 5./

---

5.3

/layer0/Layer 0/

s/to describe also/to also describe/

---

Section 5.3 contains a little surprise. "Here are the bandwidth 

augmentations: there are n bandwidth augmentations."

Perhaps resolve this by adding a paragraph at the very top of the 

section to say...

   No bandwidth augmentations are needed for this YANG module.

Then the rest of the section will appear as an explanation.

---

5.4

   The model augments all the occurrences of the label-restriction list

   with flexi-grid technology specific attributes using the flexi-grid-

   label-range-info grouping defined in [RFC9093].

Can you add a reference for where the label-restriction list is 

defined. I think it is RFC 8795.

---

7.

   module ietf-flexi-grid-topology {

     description

       "This module provides a YANG data model for the routing and

        wavelength assignment (RWA) Traffic Engineering (TE)

        topology in flexi-grid optical networks. The YANG model

        described in this document is a flexi-grid technology-specific

        YANG model augmenting the generic TE topology module

        (ietf-te-topology, RFC 9795) based on the RFC 7698 and 7699.

s/based on the RFC 7698 and 7699./based on RFC 7698 and RFC 7699./

---

7.

Obviously, the copyright date is broken in the YANG

From: CCAMP <[email-masked]> On Behalf Of Daniele Ceccarelli
Sent: 17 December 2021 14:50
To: CCAMP <[email-masked]>
Subject: [CCAMP] WG last call on draft-ietf-ccamp-flexigrid-yang-11

CCAMP,

the IPR declaration collection has been successfully completed and we can
move to the next step. Given the upcoming holiday period we'll allow for a
longer last call.

This starts a 4 weeks working group last call on
draft-ietf-ccamp-flexigrid-yang-11

The last call ends on Friday January 14th. Please send you comments to the
CCAMP mailing list.

All the IPR declarations from authors and contributors have been collected
and can be found in the history of the document
(https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexigrid-yang/history/)

If interested, please volunteer to be the shepherd of the draft (authors
excluded).

Thanks

Daniele & Fatai

---

From: <[email-masked]>
Date: Thu, 6 Jan 2022 20:35:57 -0000

Thanks, Adrian. We appreciate the review. 

It's good to have reviews, thanks WG! 

We also captured a few LC comments from Tom, and we will address all current
(and any new) issues after LC ends. 

BR, Dan. 

From: Adrian Farrel <[email-masked]> 
Sent: 06 January 2022 20:32
To: 'Daniele Ceccarelli' <[email-masked]>;
[email-masked]
Cc: 'CCAMP' <[email-masked]>
Subject: RE: [CCAMP] WG last call on draft-ietf-ccamp-flexigrid-yang-11

Hi Daniele and authors,

sorted out.

Best,

Adrian

===

Throughout:

---

---

Section 1

   flexi-grid elements.

I think this should be

   the flexi-grid elements.

---

Section 3

---

Section 4

OLD

      We also provide nodes A

NEW

      A and B.

END

---

5.1

---

5.1

---

   topology.

I think, probably...

   in this section.

---

5.2

---

5.3

/layer0/Layer 0/

---

section to say...

---

5.4

---

7.

     description

---

7.

From: CCAMP <[email-masked] <mailto:[email-masked]> > On
Behalf Of Daniele Ceccarelli
Sent: 17 December 2021 14:50
To: CCAMP <[email-masked] <mailto:[email-masked]> >
Subject: [CCAMP] WG last call on draft-ietf-ccamp-flexigrid-yang-11

CCAMP,

 

Thanks

Daniele & Fatai

---

From: tom petch <[email-masked]>
Date: Thu, 13 Jan 2022 12:32:57 +0000

From: CCAMP <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: 06 January 2022 20:35

It’s good to have reviews, thanks WG!

We also captured a few LC comments from Tom, and we will address all current (and any new) issues after LC ends.

<tp>
I commented before that I struggle with the complexity of the 'when' statements in many CCAMP and TEAS I-D such as this one.

Is it 
      when "../../../../../../../../../../"
          + "nw:network-types/tet:te-topology/"
 or
      when "../../../../../../../../../"
          + "nw:network-types/tet:te-topology/"
 or
      when "../../../../../../../nw:network-types/tet:te-topology/"
    
? answer all of them depending!

I speculated that the absolute form of the path statement would be much simpler but it was pointed out to me by Martin that that would not work as 'nw:network is a list and so would return true if 'flexi-grid-topology' appeared anywhere in the list which in this case it is almost bound to; but there is the XPath 'ancestor' function which returns true only if the value appears in an immediate ancestor of the context node.  This is almost what I want the caveat being that it returns true if any of the predicates - e.g. primary-path, route-object-exclude-object, etc -  has the value  in question but I believe that that will never be the case.

In which case, 
 when "ancestor::node()/nw:network-types/tet:te-topology"
as proposed by Lada will do the job for almost all the 'when' statements (and I can understand it ).

The thread is on the netmod WG list from 29dec21 under the subject
YANG 'when' with absolute path

Tom Petch

BR, Dan.

To: 'Daniele Ceccarelli' <[email-masked]>; [email-masked]

Hi Daniele and authors,

Best,
Adrian

===

Throughout:

---

---

Section 1

I think this should be

---

Section 3

---

Section 4

OLD
      We also provide nodes A

---

5.1

---

5.1

---

I think, probably...

---

5.2

---

5.3

/layer0/Layer 0/

---

---

5.4

---

7.

---

7.

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Daniele Ceccarelli
Sent: 17 December 2021 14:50
To: CCAMP <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] WG last call on draft-ietf-ccamp-flexigrid-yang-11

CCAMP,

the IPR declaration collection has been successfully completed and we can move to the next step. Given the upcoming holiday period we’ll allow for a longer last call.

Thanks

Daniele & Fatai

---

From: <[email-masked]>
Date: Fri, 14 Jan 2022 15:41:31 +0100

Hi CCAMPers,

After reviewing the I-D, it seems to us there's a discrepancy
between the spectrum constraints that the model intends to describe
and the representation currently mapping it into a range for n
(using flexi-grid-label-start-end). Indeed, flexi-grid channels use
different spectrum widths (m), which makes the range for n
dependent on the m of each channel to be provisioned. E.g.,
if a range is defined assuming a 62.5 GHz width, my new 75 GHz-wide
channel may not fit if the corresponding n is taken at the
range border.

A reasonable solution to that issue is to add some text defining a
reference value (e.g. 50 GHz) to be used for any
flexi-grid-label-start-end description. This would make it easy to
compute the final range for n with any m and makes
implementations future-proof on that matter. (Note that RFC 8363
doesn't face this issue because the corresponding bitmap describes
the full spectrum and not only the range for n).

How about adding the following at the end of section 5.4: "When
flexi-grid-label-start-end is used, the associated range for n MUST
be specified for 50 GHz-wide channels; this allows to compute the
exact range for any channel width the network may have to
accommodate."?

Thanks,

Esther & Julien

On 17/12/2021 15:50, Daniele Ceccarelli
wrote:

CCAMP,

the IPR declaration
collection has been successfully completed and we can move
to the next step. Given the upcoming holiday period we’ll
allow for a longer last call.

This starts a 4
weeks working group last call on
draft-ietf-ccamp-flexigrid-yang-11

The last call ends on Friday
January 14th. Please send you comments to
the CCAMP mailing list.

All the IPR declarations
from authors and contributors have been collected and can be
found in the history of the document (https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexigrid-yang/history/)

If interested, please
volunteer to be the
shepherd of the draft (authors excluded).

Thanks

Daniele &
Fatai

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 14 Jan 2022 16:12:09 +0000

Hi Julien,

I'm not sure i understood the issue.
I assume the width you're referring to is 6.25 GHz and not 62.5 GHz, in that case the 75 GHz wide channel will be identified by m=6. I don't get what is the issue with n being at the range border...could you elaborate a bit please?
Thanks,
Daniele

From: CCAMP <[email-masked]> On Behalf Of [email-masked]
Sent: den 14 januari 2022 15:42
To: [email-masked]
Subject: Re: [CCAMP] WG last call on draft-ietf-ccamp-flexigrid-yang-11

Hi CCAMPers,

After reviewing the I-D, it seems to us there's a discrepancy between the spectrum constraints that the model intends to describe and the representation currently mapping it into a range for n (using flexi-grid-label-start-end). Indeed, flexi-grid channels use different spectrum widths (m), which makes the range for n dependent on the m of each channel to be provisioned. E.g., if a range is defined assuming a 62.5 GHz width, my new 75 GHz-wide channel may not fit if the corresponding n is taken at the range border.

A reasonable solution to that issue is to add some text defining a reference value (e.g. 50 GHz) to be used for any flexi-grid-label-start-end description. This would make it easy to compute the final range for n with any m and makes implementations future-proof on that matter. (Note that RFC 8363 doesn't face this issue because the corresponding bitmap describes the full spectrum and not only the range for n).
How about adding the following at the end of section 5.4: "When flexi-grid-label-start-end is used, the associated range for n MUST be specified for 50 GHz-wide channels; this allows to compute the exact range for any channel width the network may have to accommodate."?

Thanks,

Esther & Julien

On 17/12/2021 15:50, Daniele Ceccarelli wrote:
CCAMP,

Thanks

Daniele & Fatai

CCAMP mailing list

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

Thank you.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 14 Jan 2022 16:20:21 +0000

WG,

There are many comments against the draft but no major one preventing it to proceed in the process.
Authors please solve the comments raised during the last call and update the draft status to standard track (if I'm not mistaken Italo already noted it).
Once the draft is updated we'll submit it to the IESG for publication.

Thanks
Daniele

From: CCAMP <[email-masked]> On Behalf Of Daniele Ceccarelli
Sent: den 17 december 2021 15:50
To: CCAMP <[email-masked]>
Subject: [CCAMP] WG last call on draft-ietf-ccamp-flexigrid-yang-11

CCAMP,

All the IPR declarations from authors and contributors have been collected and can be found in the history of the document (https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexigrid-yang/history/<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-e2efedf638682582&q=1&e=2bd38135-3c53-41c1-b9ff-e1595c175b77&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ccamp-flexigrid-yang%2Fhistory%2F>)
If interested, please volunteer to be the shepherd of the draft (authors excluded).

Thanks

Daniele & Fatai

---

From: tom petch <[email-masked]>
Date: Fri, 14 Jan 2022 17:10:53 +0000

got a bounce message for my last post on this thread for 

[email-masked]

Tom Petch

From: CCAMP <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 13 January 2022 12:32

<tp>

Is it

In which case,

Tom Petch

BR, Dan.

Hi Daniele and authors,

Best,
Adrian

===

Throughout:

---

---

Section 1

I think this should be

---

Section 3

---

Section 4

OLD
      We also provide nodes A

---

5.1

---

5.1

---

I think, probably...

---

5.2

---

5.3

/layer0/Layer 0/

---

---

5.4

---

7.

---

7.

CCAMP,

Thanks

Daniele & Fatai

---

From: Italo Busi <[email-masked]>
Date: Mon, 17 Jan 2022 17:46:29 +0000

Daniele, Julien, Esther,

If we have understood well the comment from Julien&Esther, with a reference to figure 3 of RFC 8363:

      -9 -8 -7 -6 -5 -4 -3 -2 -1 0  1  2  3  4  5  6  7  8  9 10  11
   ...+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--...
                           |--Available Frequency Range--|

                  Figure 3: Flexi-Grid DWDM Link Example

The issue is that if n=-1 is advertised as an available label, it is possible to setup a frequency slot with n=-1 and m=1 but not a frequency slot with n=-1 and m=2. Therefore the advertised available nominal central frequencies should be always correlated with a reference spectrum width

In fact, section 3.1 of RFC8363 clarifies that:

   <...> Available
   central frequencies are advertised for m=1, which means that for an
   available central frequency n, the frequency slot from central
   frequency n-1 to central frequency n+1 is available

If we understand correctly, the proposal from Julien&Esther is to advertise the range of the available values of n for m=4 (50GHz)

We are wondering why not aligning the flexi-grid topology with the approach used in RFC8363 and to clarify that the available nominal central frequencies are correlated with m=1

We are also wondering whether this clarification should be provided in the flexi-grid I-D or in the layer0-types that defines the re-usable grouping used to describe the nominal central frequencies availability

Sergio and Italo

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: venerdì 14 gennaio 2022 17:12
To: [email-masked]; [email-masked]
Subject: Re: [CCAMP] WG last call on draft-ietf-ccamp-flexigrid-yang-11

Hi Julien,

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: den 14 januari 2022 15:42
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] WG last call on draft-ietf-ccamp-flexigrid-yang-11

Hi CCAMPers,

Thanks,

Esther & Julien

Thanks

Daniele & Fatai

CCAMP mailing list

Thank you.

---

From: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Mon, 17 Jan 2022 18:25:44 +0000

Daniele, Julien, Esther and Italo,

Usually the elementary slot position in given by the ROADM (and by the ITU look at G.694.1 fig. I.2 and I.3 and the description) and it is fixed.
If we consider m granularity = 12.5 then it is very likely (if not always by ITU definition) that we have the elementary slot fitting in n=0 position (so from n= -1 and n= +1)
Like the diagram below.

ROADM (m)    +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+...

             -9 -8 -7 -6 -5 -4 -3 -2 -1 0  1  2  3  4  5  6  7  8  9 10  11
Centr. (n)   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+...
                           |--Available Frequency Range--|

So why the n granularity is 6.25 ? Simple: because we can have channels with m odd and even.
If even (e.g. 4), then the central frequency is between two ROADM elementary slots (n is odd), if m is odd then the
Central frequency is in the middle of an elementary slot (n is even),  (look again at G.694.1 fig. I.2 and I.3 and the description).

For sure We can NOT move the elementary slots position (unless changing the ROADM and all the ITU specs).

So Italo what You say: “”, it is possible to setup a frequency slot with n=-1 and m=1 “”  is not possible, if n= -1 m is always 2 (or even value).

Finally if You change the grid (e.g. ITU-T 50GHz) things don’t change, the slot central freq. will fit at n=0

I hope it is more clear now.

Best Regards,

Gabriele

From: CCAMP <[email-masked]> on behalf of Italo Busi <Italo.Busi=[email-masked]>
Date: Monday, 17 January 2022 at 18:47
To: 'Daniele Ceccarelli' <[email-masked]>, "julien.meuric" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [CCAMP] WG last call on draft-ietf-ccamp-flexigrid-yang-11

Daniele, Julien, Esther,

   <...> Available

Sergio and Italo

Hi Julien,

I’m not sure i understood the issue.
I assume the width you’re referring to is 6.25 GHz and not 62.5 GHz, in that case the 75 GHz wide channel will be identified by m=6. I don’t get what is the issue with n being at the range border…could you elaborate a bit please?
Thanks,
Daniele

Hi CCAMPers,

Thanks,

Esther & Julien

Thanks

Daniele & Fatai

CCAMP mailing list

Thank you.

---

From: <[email-masked]>
Date: Tue, 18 Jan 2022 14:12:43 +0100

Ciao Daniele,

Sorry if it's unclear. I use the term "width" to refer to channels,
not to grid granularity, so I really meant 62.5 GHz.

The issue here would be the same whatever the grid: given the
variety of channel widths (m values), there's no universal way to
specify a range for n because it depends on the m to come. Italo's
proposal to define it for m=1 is reasonable and allows to compute
the resulting spectral bandwidth for any m, when new channels are
admitted.

Thanks,

Julien

On 14/01/2022 17:12, Daniele Ceccarelli
wrote:

Hi Julien,

I’m
not sure i understood the issue.

I
assume the width you’re referring to is 6.25 GHz and not
62.5 GHz, in that case the 75 GHz wide channel will be
identified by m=6. I don’t get what is the issue with n
being at the range border…could you elaborate a bit please?

Thanks,

Daniele

From: CCAMP <[email-masked]>
On Behalf Of [email-masked]

Hi CCAMPers,

After reviewing the I-D, it seems to us there's a
discrepancy between the spectrum constraints that the model
intends to describe and the representation currently mapping
it into a range for
n (using flexi-grid-label-start-end). Indeed,
flexi-grid channels use different spectrum widths (m),
which makes the range for
n dependent on the m of each channel to be
provisioned. E.g., if a range is defined assuming a 62.5 GHz
width, my new 75 GHz-wide channel may not fit if the
corresponding
n is taken at the range border.

A reasonable solution to that issue is to add some text
defining a reference value (e.g. 50 GHz) to be used for any
flexi-grid-label-start-end description. This would make it
easy to compute the final range for
n with any m and makes implementations
future-proof on that matter. (Note that RFC 8363 doesn't
face this issue because the corresponding bitmap describes
the full spectrum and not only the range for
n).

How about adding the following at the end of section 5.4:
"When flexi-grid-label-start-end is used, the associated
range for n MUST be specified for 50 GHz-wide channels; this
allows to compute the exact range for any channel width the
network may have to accommodate."?

Thanks,

Esther & Julien

CCAMP,

the IPR declaration
collection has been successfully completed and we can
move to the next step. Given the upcoming holiday period
we’ll allow for a longer last call.

This starts a 4

The last call ends
on Friday January 14th. Please send
you comments to the CCAMP mailing list.

All the IPR
declarations from authors and contributors have been
collected and can be found in the history of the
document (https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexigrid-yang/history/)

If interested,
please volunteer to be the
shepherd of the draft (authors excluded).

Thanks

Daniele &
Fatai

CCAMP mailing list

[email-masked]

---

From: <[email-masked]>
Date: Tue, 18 Jan 2022 14:13:32 +0100

Ciao Italo,

Thank you, I think you got our point.

Leaving the odd/even issue apart, we agree that using m=1 for
n-ranges is simpler than m=4 and we fully support your proposal.
E.g., "the range for n MUST be specified for a fixed value of m=1; this allows to compute the exact range for any channel
width the network may have to accommodate."

Cheers,

Esther & Julien

On 17/01/2022 18:46, Italo Busi wrote:

Daniele,
Julien, Esther,

If we have
understood well the comment from Julien&Esther, with a
reference to figure 3 of RFC 8363:

-9 -8 -7 -6 -5
-4 -3 -2 -1 0  1  2  3  4  5  6  7  8  9 10  11

The issue
is that if n=-1 is advertised as an available label, it is
possible to setup a frequency slot with n=-1 and m=1 but not
a frequency slot with n=-1 and m=2. Therefore the advertised
available nominal central frequencies should be always
correlated with a reference spectrum width

In fact,
section 3.1 of RFC8363 clarifies that:

<...>
Available

central frequencies
are advertised for m=1, which means that for an

available central
frequency n, the frequency slot from central

frequency n-1 to
central frequency n+1 is available

If we
understand correctly, the proposal from Julien&Esther is
to advertise the range of the available values of n for m=4
(50GHz)

We are
wondering why not aligning the flexi-grid topology with the
approach used in RFC8363 and to clarify that the available
nominal central frequencies are correlated with m=1

We are also
wondering whether this clarification should be provided in
the flexi-grid I-D or in the layer0-types that defines the
re-usable grouping used to describe the nominal central
frequencies availability

Sergio and
Italo

From:
Daniele Ceccarelli
[mailto:[email-masked]]

Hi
Julien,

I’m not
sure i understood the issue.

I assume
the width you’re referring to is 6.25 GHz and not 62.5
GHz, in that case the 75 GHz wide channel will be
identified by m=6. I don’t get what is the issue with n
being at the range border…could you elaborate a bit
please?

Thanks,

Daniele

From:
CCAMP <[email-masked]>
On Behalf Of [email-masked]

Hi CCAMPers,

After reviewing the I-D, it seems to us there's a
discrepancy between the spectrum constraints that the
model intends to describe and the representation
currently mapping it into a range for
n (using flexi-grid-label-start-end). Indeed,
flexi-grid channels use different spectrum widths (m),
which makes the range for
n dependent on the m of each channel to
be provisioned. E.g., if a range is defined assuming a
62.5 GHz width, my new 75 GHz-wide channel may not fit
if the corresponding
n is taken at the range border.

A reasonable solution to that issue is to add some text
defining a reference value (e.g. 50 GHz) to be used for
any flexi-grid-label-start-end description. This would
make it easy to compute the final range for
n with any m and makes implementations
future-proof on that matter. (Note that RFC 8363 doesn't
face this issue because the corresponding bitmap
describes the full spectrum and not only the range for
n).

How about adding the following at the end of section
5.4: "When flexi-grid-label-start-end is used, the
associated range for n MUST be specified for 50 GHz-wide
channels; this allows to compute the exact range for any
channel width the network may have to accommodate."?

Thanks,

Esther & Julien

On 17/12/2021 15:50,
Daniele Ceccarelli wrote:

CCAMP,

the IPR declaration collection has
been successfully completed and we can move to the next
step. Given the upcoming holiday period we’ll allow for
a longer last call.

This starts a 4 weeks working
group last call on
draft-ietf-ccamp-flexigrid-yang-11

The last call ends on Friday
January 14th. Please send you comments
to the CCAMP mailing list.

All the IPR declarations from authors
and contributors have been collected and can be found in
the history of the document (https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexigrid-yang/history/)

If interested, please volunteer to be
the shepherd of the draft (authors excluded).

Thanks

Daniele & Fatai

CCAMP mailing list

[email-masked]

---

From: <[email-masked]>
Date: Tue, 18 Jan 2022 15:05:52 +0100

Ciao Gabriele,

Thanks for your feedback. Your use of the ITU-T specification is
clever and we wish it were so deterministic. Unfortunately, it seems
that Figure I.1 of G.694.1 contradicts your summary because it
includes a set of channels with an even m associated to a mix of odd
n and even n.

Regards,

Esther & Julien

On 17/01/2022 19:25, Gabriele Maria
Galimberti (ggalimbe) wrote:

Usually the elementary slot position in given
by the ROADM (and by the ITU look at G.694.1 fig. I.2 and
I.3 and the description) and it is fixed.

If we consider m granularity = 12.5 then it is
very likely (if not always by ITU definition) that we have
the elementary slot fitting in n=0 position (so from n= -1
and n= +1)

Like the diagram below.

ROADM
(m)    +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+...

-9 -8 -7 -6 -5 -4 -3
-2 -1 0  1  2  3  4  5  6  7  8  9 10  11

Centr.
(n)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+...

So why the n granularity is 6.25 ? Simple:
because we can have channels with m odd and even.

If even (e.g. 4), then the central frequency is
between two ROADM elementary slots (n is odd), if m is odd
then the

Central frequency is in the middle of an
elementary slot (n is even),  (look again at G.694.1 fig.
I.2 and I.3 and the description).

For sure We can NOT move the elementary slots
position (unless changing the ROADM and all the ITU specs).

So Italo what You say: “”, it is possible to
setup a frequency slot with n=-1 and m=1 “”  is not
possible, if n= -1 m is always 2 (or even value).

Finally if You change the grid (e.g. ITU-T
50GHz) things don’t change, the slot central freq. will fit
at n=0

Best Regards,

Gabriele

From:
CCAMP <[email-masked]> on
behalf of Italo Busi
<Italo.Busi=[email-masked]>

Daniele, Julien, Esther,

If we have understood well the comment from
Julien&Esther, with a reference to figure 3 of RFC 8363:

-9
-8 -7 -6 -5 -4 -3 -2 -1 0  1  2  3  4  5  6  7  8  9 10  11

The issue is that if n=-1 is advertised as an
available label, it is possible to setup a frequency slot
with n=-1 and m=1 but not a frequency slot with n=-1 and
m=2. Therefore the advertised available nominal central
frequencies should be always correlated with a reference
spectrum width

<...> Available

central frequencies are advertised for m=1, which means that
for an

available central frequency n, the frequency slot from
central

If we understand correctly, the proposal from
Julien&Esther is to advertise the range of the available
values of n for m=4 (50GHz)

We are wondering why not aligning the
flexi-grid topology with the approach used in RFC8363 and to
clarify that the available nominal central frequencies are
correlated with m=1

We are also wondering whether this
clarification should be provided in the flexi-grid I-D or in
the layer0-types that defines the re-usable grouping used to
describe the nominal central frequencies availability

Sergio and Italo

From: Daniele Ceccarelli

Hi
Julien,

I assume the width you’re referring to is
6.25 GHz and not 62.5 GHz, in that case the 75 GHz wide
channel will be identified by m=6. I don’t get what is the
issue with n being at the range border…could you elaborate
a bit please?

Thanks,

Daniele

Hi CCAMPers,

Thanks,

Esther & Julien

On 17/12/2021 15:50,

CCAMP,

the IPR
declaration collection has been successfully completed
and we can move to the next step. Given the upcoming
holiday period we’ll allow for a longer last call.

This starts a 4

The last call ends

All the IPR

If interested,

Thanks

Daniele
& Fatai

CCAMP mailing list

[email-masked]

---

From: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Tue, 18 Jan 2022 14:22:56 +0000

Ciao Julien,

I agree with You, the picture is misleading.
If somebody does the implementation depicted in fig I.1 it would waist the 50% of the elementary slots (at 12.5 GHz) at the side of the channels and an overlapping of the two
adjacent channels sharing the same elementary slot.
Note, the ROADM is able to switch the elementary slot(s) so how will the shared elementary slot be provisioned if the two channels are following a different route ?
That is not going to happen.

In summary … theoretically everything can be done but when You have physical components we have to be careful.

Best Regards,

Gabriele

From: <[email-masked]>
Organisation: Orange
Date: Tuesday, 18 January 2022 at 15:06
To: Gabriele Galimberti <[email-masked]>
Cc: Italo Busi <[email-masked]>, 'Daniele Ceccarelli' <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [CCAMP] WG last call on draft-ietf-ccamp-flexigrid-yang-11

Ciao Gabriele,

Thanks for your feedback. Your use of the ITU-T specification is clever and we wish it were so deterministic. Unfortunately, it seems that Figure I.1 of G.694.1 contradicts your summary because it includes a set of channels with an even m associated to a mix of odd n and even n.

Regards,

Esther & Julien

On 17/01/2022 19:25, Gabriele Maria Galimberti (ggalimbe) wrote:
Daniele, Julien, Esther and Italo,

Best Regards,

Gabriele

From: CCAMP <[email-masked]><mailto:[email-masked]> on behalf of Italo Busi <Italo.Busi=[email-masked]><mailto:Italo.Busi=[email-masked]>
Date: Monday, 17 January 2022 at 18:47

Daniele, Julien, Esther,

   <...> Available

Sergio and Italo

Hi Julien,

Hi CCAMPers,

Thanks,

Esther & Julien

Thanks

Daniele & Fatai

CCAMP mailing list