Subject: [CCAMP] ODU4 and ODUCn discussion

From: Gert Grammel <[email-masked]>
Date: Thu, 17 Nov 2016 08:18:27 +0000

After the ccamp meeting Daniele suggested to briefly sum up the issues on more detail on the list to trigger a discussion. As Fatai mentioned, ODU4 is incompatible with ODUC1 which looked surprising to most of us. Consulting https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-10-05-itu-t-sg-15-mpls-ccamp-pce-ls-on-sg15-otnt-standardization-work-plan-attachment-3.pdf didn’t provide many more details:
The 5th edition of Recommendation ITU-T G.709/Y.1331 “Interfaces for the Optical Transport Network”,
published in June 2016, enables optical transport at rates higher than 100 Gbit/s (the code name is beyond 100 Gbit/s or B100G).
Details of G.709 are given in Part 1 of this document.
So some clarity about whether 100G is actually considered “beyond 100G” is appreciated. If indeed ODU4 is incompatible with ODUC1, it would be great to get some color about why both options are needed and what are their particularities. Such understanding would really help to get the control plane work right.

Based on my current understanding (ODU4 and ODUC1 are incompatible versions of ODU) here a few technical questions that would need to be addressed in GMPLS:

1.       ODU4 and ODUC1 are both 100G, so what will be the bandwidth to be encoded? See RFC3471  3.1.2<https://tools.ietf.org/html/rfc3471#section-3.1.2>. Bandwidth Encoding

a.       Seems to be a solvable issue

2.       A use case to consider is:

          +----------+                     +----------------+                      +-----------+
100GE ----|-GMP-ODU4-|-OTU4-----------OTU4-|-ODU4-GMP-ODUC1-|-OTUC1----------OTUC1-|-ODUC1-GMP-|----100GE
          +----------+                     +----------------+                      +-----------+
              NE1                            NE2 (=GW-NE)                              NE3

3.  Considering NE1 is an existing Gen-1 device (ODU4 only), while NE2+NE3 are new Gen-2 (ODUC+ODU4 capable) devices. The service provided is a 100G Ethernet p2p service.

a.  How is such a service signaled? (remark: A good starting point could be the stitching model used in MPLS)

                        i.   One RSVP session per service?

                      ii.   One RSVP session per ODU (abstracting ODU4/ODUC1 details?)

                    iii.   Two separate signaling sessions: ODU4 and ODUC1 each

                      iv.   Three sessions: one for the 100GE and two server layer sessions one for each ODU?

b.  How does ODU-OAM work?

                        i.   Is there a TCM session available for the service i.e. between ingress on NE1 and egress on NE3?

                      ii.   How would other ODU OAM propagate in the data plane? i.e. AIS, RDI, …

                    iii.   If OAM doesn’t pass on the date-plane is there a need to substitute by control plane? i.e. generate something like an ODU-AIS in GMPLS once one of the ODU segments is cut to inform the other ODU segment?

c.  How would the whole thing work in case of ODUflex is used? (number of sessions, encoding etc)

                        i.   Would it matter if an ODUflex is put in an OTU4 vs OTUC1 or is it the same?

                      ii.   Would all the ODUflex-OAM stuff pass transparently through NE2?

d.  If LO ODUs such as 8*ODU2 are transported over an ODU4/ODUC1, are those ODU2 still the same i.e. pass transparently through the GW-NE or is there anything to consider on ODU2 level too?

e.  Do we need to consider re-programmable interfaces that can be set to ODU4/OTU4 XOR ODUC1/OTUC1 prior or during the signaling passes along?

4.       For wavelength switching a similar concern exists related to OTUC1 vs OTU4

a.       What would be the BW encoding for each?

b.       A regenerator device may regenerate an ODU4/OTU4 on ingress to ODUC1/OTUC1 on egress. How would that be signaled? (same discussion as for ODU)

c.       OTUCn may consist of several carriers (i.e. wavelength, think it is called OTSi)?

                                                               i.      If so, are the available mechanisms in GMPLS sufficient to co-route these?

                                                             ii.      Would it then be one RSVP session per carrier or one per OTUCn?

To sum up:

-          Keeping GMPLS in sync with available dataplane standards is a good working practice that should continue

-          At this point, it doesn’t appear that the implications of introducing ODUC1 into GMPLS are sufficiently clear

-          It would be prudent to delay the decision whether a framework document is required once technical clarification is available.

Best

Gert

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 17 Nov 2016 17:06:12 +0100

Hello Gert,

Your use case is not completely correct.

Instead of:

2.
A use case to consider is:

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

100GE--|-GMP-ODU4-|-OTU4---OTU4-|-ODU4-GMP-ODUC1-|-OTUC1---OTUC1-|-ODUC1-GMP-|--100GE

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

NE1                    NE2
(=GW-NE)                       NE3

It should be:

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

100GE--|-GMP-ODU4-|-OTU4---OTU4-|-ODU4-GMP-ODUC1-|-OTUC1---OTUC1-|-ODUC1-GMP-ODU4-GMP-|--100GE

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

NE1                    NE2
(=GW-NE)                       NE3

The ODUC1 from NE2 to NE3 tunnels the ODU4.

Regards, Huub.

--
================================================================
Always remember that you are unique...just like everyone else...

---

From: [email-masked]
Date: Fri, 18 Nov 2016 09:14:41 +0800

Hi Huub,

You are correct.

Thanks
Qilei

Huub van Helvoort <[email-masked]> 
发件人:  "CCAMP" <[email-masked]>
2016/11/18 00:06
请答复 给
[email-masked]

收件人
[email-masked], 
抄送

主题
Re: [CCAMP] ODU4 and ODUCn discussion

Hello Gert,

Instead of:

+-----------+
+-----------+   
             NE1                    NE2 (=GW-NE)                       NE3

It should be: 

-- 
================================================================
Always remember that you are unique...just like everyone else...
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: [email-masked]
Date: Fri, 18 Nov 2016 09:18:20 +0800

Hi Gert,

It looks like there are many issues needed to be resolved. I will check 
with other experts first to see if my understanding is right or not, and 
then get back to the list.

Thanks
Qilei

Gert Grammel <[email-masked]> 
发件人:  "CCAMP" <[email-masked]>
2016/11/17 16:18

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

主题
[CCAMP] ODU4 and ODUCn discussion

After the ccamp meeting Daniele suggested to briefly sum up the issues on 
more detail on the list to trigger a discussion. As Fatai mentioned, ODU4 
is incompatible with ODUC1 which looked surprising to most of us. 
Consulting 
https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-10-05-itu-t-sg-15-mpls-ccamp-pce-ls-on-sg15-otnt-standardization-work-plan-attachment-3.pdf 
didn’t provide many more details:
The 5th edition of Recommendation ITU-T G.709/Y.1331 “Interfaces for the 
Optical Transport Network”, 
published in June 2016, enables optical transport at rates higher than 100 
Gbit/s (the code name is beyond 100 Gbit/s or B100G).
Details of G.709 are given in Part 1 of this document.
So some clarity about whether 100G is actually considered “beyond 100G” 
is appreciated. If indeed ODU4 is incompatible with ODUC1, it would be 
great to get some color about why both options are needed and what are 
their particularities. Such understanding would really help to get the 
control plane work right.
 
Based on my current understanding (ODU4 and ODUC1 are incompatible 
versions of ODU) here a few technical questions that would need to be 
addressed in GMPLS:
 
1.       ODU4 and ODUC1 are both 100G, so what will be the bandwidth to be 
encoded? See RFC3471  3.1.2. Bandwidth Encoding
a.       Seems to be a solvable issue
2.       A use case to consider is:
 
          +----------+                     +----------------+  
+-----------+
100GE 
----|-GMP-ODU4-|-OTU4-----------OTU4-|-ODU4-GMP-ODUC1-|-OTUC1----------OTUC1-|-ODUC1-GMP-|----100GE
          +----------+                     +----------------+  
+-----------+ 
              NE1                            NE2 (=GW-NE)             NE3
 
3.  Considering NE1 is an existing Gen-1 device (ODU4 only), while NE2+NE3 
are new Gen-2 (ODUC+ODU4 capable) devices. The service provided is a 100G 
Ethernet p2p service.
a.  How is such a service signaled? (remark: A good starting point could 
be the stitching model used in MPLS)
                        i.   One RSVP session per service? 
                      ii.   One RSVP session per ODU (abstracting 
ODU4/ODUC1 details?) 
                    iii.   Two separate signaling sessions: ODU4 and ODUC1 
each
                      iv.   Three sessions: one for the 100GE and two 
server layer sessions one for each ODU?
b.  How does ODU-OAM work?
                        i.   Is there a TCM session available for the 
service i.e. between ingress on NE1 and egress on NE3?
                      ii.   How would other ODU OAM propagate in the data 
plane? i.e. AIS, RDI, …
                    iii.   If OAM doesn’t pass on the date-plane is there 
a need to substitute by control plane? i.e. generate something like an 
ODU-AIS in GMPLS once one of the ODU segments is cut to inform the other 
ODU segment?
c.  How would the whole thing work in case of ODUflex is used? (number of 
sessions, encoding etc)
                        i.   Would it matter if an ODUflex is put in an 
OTU4 vs OTUC1 or is it the same? 
                      ii.   Would all the ODUflex-OAM stuff pass 
transparently through NE2?
d.  If LO ODUs such as 8*ODU2 are transported over an ODU4/ODUC1, are 
those ODU2 still the same i.e. pass transparently through the GW-NE or is 
there anything to consider on ODU2 level too?
e.  Do we need to consider re-programmable interfaces that can be set to 
ODU4/OTU4 XOR ODUC1/OTUC1 prior or during the signaling passes along?
4.       For wavelength switching a similar concern exists related to 
OTUC1 vs OTU4
a.       What would be the BW encoding for each?
b.       A regenerator device may regenerate an ODU4/OTU4 on ingress to 
ODUC1/OTUC1 on egress. How would that be signaled? (same discussion as for 
ODU)
c.       OTUCn may consist of several carriers (i.e. wavelength, think it 
is called OTSi)? 
                                                               i.      If 
so, are the available mechanisms in GMPLS sufficient to co-route these? 
                                                             ii. Would it 
then be one RSVP session per carrier or one per OTUCn? 
 
To sum up:
-          Keeping GMPLS in sync with available dataplane standards is a 
good working practice that should continue
-          At this point, it doesn’t appear that the implications of 
introducing ODUC1 into GMPLS are sufficiently clear
-          It would be prudent to delay the decision whether a framework 
document is required once technical clarification is available.
 
Best
 
Gert_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Gert Grammel <[email-masked]>
Date: Fri, 18 Nov 2016 01:46:35 +0000

Yes, please go ahead. As Huub mentioned, the case may not be 100% accurate which is already a good point to start with. It’s really about getting a clear picture.

Gert

From: "[email-masked]" <[email-masked]>
Date: Friday 18 November 2016 at 10:18
To: Gert Grammel <[email-masked]>, CCAMP <[email-masked]>
Subject: Re: [CCAMP] ODU4 and ODUCn discussion

Hi Gert,

It looks like there are many issues needed to be resolved. I will check with other experts first to see if my understanding is right or not, and then get back to the list.

Thanks
Qilei

2016/11/17 16:18

收件人

CCAMP <[email-masked]>,

抄送

主题

To sum up:

Best

---

From: Gert Grammel <[email-masked]>
Date: Fri, 18 Nov 2016 02:01:59 +0000

Huub,

Thanks for clarifying. The aim of this thread is to converge on a clear picture so that we can gauge what’s needed on CP level to support.
From your explanation it seems there are 3 different ways to map 100GE into an ODU

·         100GE—GMP---ODU4---OTU4

·         100GE—GMP---ODUC1---OTUC1

·         100GE---GMP---ODU4---ODUC1---OTUC1
Is that correct or are there still more options. I.e. not so clear how to deal with ODUflex of some kind and maybe GFP-F mapping is also still an option. Presumably there are also options like n times ODU2 in ODUC1 (is n still limited to 8 in this case?).

Thanks

Gert

From: CCAMP <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Friday 18 November 2016 at 10:14
To: "[email-masked]" <[email-masked]>
Cc: CCAMP <[email-masked]>, CCAMP <[email-masked]>
Subject: Re: [CCAMP] ODU4 and ODUCn discussion

Hi Huub,

You are correct.

Thanks
Qilei

2016/11/18 00:06
请答复 给
[email-masked]

收件人

[email-masked],

抄送

主题

Hello Gert,

Instead of:

It should be:

       +----------+             +----------------+               +--------------------+
100GE--|-GMP-ODU4-|-OTU4---OTU4-|-ODU4-GMP-ODUC1-|-OTUC1---OTUC1-|-ODUC1-GMP-ODU4-GMP-|--100GE
       +----------+             +----------------+               +--------------------+

             NE1                    NE2 (=GW-NE)                       NE3

Regards, Huub.

--
================================================================
Always remember that you are unique...just like everyone else..._______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: [email-masked]
Date: Fri, 18 Nov 2016 10:10:23 +0800

Hi Gert,

I don't think the second way is correct. Because as defined in G.709, 
ODUCn can only be used to carry OTN clients(i.e., ODU0, ODU1...,ODU4).

Thanks
Qilei

2016/11/18 10:01

收件人
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, 
抄送
"[email-masked]" <[email-masked]>, CCAMP <[email-masked]>
主题
Re: [CCAMP] ODU4 and ODUCn discussion

Huub,
 
Thanks for clarifying. The aim of this thread is to converge on a clear 
picture so that we can gauge what’s needed on CP level to support.
From your explanation it seems there are 3 different ways to map 100GE 
into an ODU
・         100GE―GMP---ODU4---OTU4
・         100GE―GMP---ODUC1---OTUC1
・         100GE---GMP---ODU4---ODUC1---OTUC1
Is that correct or are there still more options. I.e. not so clear how to 
deal with ODUflex of some kind and maybe GFP-F mapping is also still an 
option. Presumably there are also options like n times ODU2 in ODUC1 (is n 
still limited to 8 in this case?).
 
Thanks
 
Gert
 
From: CCAMP <[email-masked]> on behalf of "[email-masked]" 
<[email-masked]>
 
Hi Huub, 

You are correct. 

Thanks 
Qilei

请答复 给
[email-masked]

收件人
[email-masked], 
抄送

主题

Hello Gert,

Instead of:

It should be: 

             NE1                    NE2 (=GW-NE)                       NE3

---

From: Gert Grammel <[email-masked]>
Date: Fri, 18 Nov 2016 02:25:06 +0000

Qilei,

Looking forward, would that then mean that a 400GE would need to be mapped into an ODU5 before it goes into an ODUC4? Is such ODU5 already defined? I am probably a bit confused about all the options and guess the WG is so too. I like to refrain here from further guessing as it may even add to confusion much more than clarifying anything. It would be great if you and/or Huub could come up with a description/presentation that can be consumed more easily than an email thread as a basis for further discussion. At least this way we would have a technically correct use case that can be used for further elaboration.

Thanks
Gert

From: "[email-masked]" <[email-masked]>
Date: Friday 18 November 2016 at 11:10
To: Gert Grammel <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: CCAMP <[email-masked]>
Subject: Re: [CCAMP] ODU4 and ODUCn discussion

Hi Gert,

I don't think the second way is correct. Because as defined in G.709, ODUCn can only be used to carry OTN clients(i.e., ODU0, ODU1...,ODU4).

Thanks
Qilei

2016/11/18 10:01

收件人

"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>,

抄送

主题

Huub,

Thanks for clarifying. The aim of this thread is to converge on a clear picture so that we can gauge what’s needed on CP level to support.
From your explanation it seems there are 3 different ways to map 100GE into an ODU
•         100GE—GMP---ODU4---OTU4
•         100GE—GMP---ODUC1---OTUC1
•         100GE---GMP---ODU4---ODUC1---OTUC1
Is that correct or are there still more options. I.e. not so clear how to deal with ODUflex of some kind and maybe GFP-F mapping is also still an option. Presumably there are also options like n times ODU2 in ODUC1 (is n still limited to 8 in this case?).

Thanks

Gert

Hi Huub,

You are correct.

Thanks
Qilei

2016/11/18 00:06

请答复 给
[email-masked]

收件人

[email-masked],

抄送

主题

Hello Gert,

Instead of:

It should be:

             NE1                    NE2 (=GW-NE)                       NE3

Regards, Huub.

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 18 Nov 2016 12:54:33 +0100

Gert,

You reply:

Thanks for
clarifying. The aim of this thread is to converge on a clear
picture so that we can gauge what’s needed on CP level to
support.

The clear picture you are looking for is Figure 7-1 of G.709 (2016).

From your
explanation it seems there are 3 different ways to map 100GE
into an ODU

·
100GE—GMP---ODU4---OTU4

OK.

·
100GE—GMP---ODUC1---OTUC1

No, not in G.709/Figure 7-1

·
100GE---GMP---ODU4---ODUC1---OTUC1

Almost correct. It is 100GE---GMP---ODU4---GMP---ODUC1---OTUC1
(as I mentioned in my previous email.

Is that correct
or are there still more options.

That is the current situation.

I.e. not so
clear how to deal with ODUflex of some kind and maybe GFP-F
mapping is also still an option.

That is relevant only when you want to transport a client signal
with a bandwidth

different from 100GE.

Presumably
there are also options like n times ODU2 in ODUC1 (is n
still limited to 8 in this case?).

Gain llok at G.709/Figure 7-1.

Regards, Huub.

From:
CCAMP
<[email-masked]> on behalf of
"[email-masked]" <[email-masked]>

To: "[email-masked]"
<[email-masked]>

Cc: CCAMP <[email-masked]>, CCAMP
<[email-masked]>

Hi
Huub,

You
are correct.

Thanks

Qilei

Huub
van Helvoort <[email-masked]>

发件人:
"CCAMP" <[email-masked]>

2016/11/18
00:06

请答复
给

[email-masked]

收件人

[email-masked],

抄送

主题

Re:

Hello Gert,

Instead of:

2.
A use case to
consider is:

NE1                    NE2 (=GW-NE)
NE3

It should be:

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

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

NE1                    NE2 (=GW-NE)
NE3

Regards, Huub.

--

Always remember that you are unique...just like everyone
else..._______________________________________________

CCAMP mailing list

[email-masked]

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 18 Nov 2016 13:13:34 +0100

Gert,

You wrote:

Looking forward,
would that then mean that a 400GE would need to be mapped into
an ODU5 before it goes into an ODUC4?

Why?

This is pure speculation.

IEEE has to define 400GE before ITU-T can describe the mapping.

IMHO the best option would be mapping the 400GE via GMP into an
OPUC4.

I hope that they avoid an OPUC4e...

Is such ODU5
already defined?

No!  Read G.709 (2016) especially figure 7-1.

I am probably a
bit confused about all the options and guess the WG is so too.

I hope this and my previous email makes it clear that there are only

two options for 100GE and there will be 1 solution for 400GE.

I like to refrain
here from further guessing as it may even add to confusion
much more than clarifying anything. It would be great if you
and/or Huub could come up with a description/presentation that
can be consumed more easily than an email thread as a basis
for further discussion.

Because a picture can tell you more than a thousand words I
recommend

to look at  G.709 (2016) Figure 7-1.

Regards, Huub.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 18 Nov 2016 17:39:27 +0000

Thanks for the clear explanation Huub.

I see two different use cases that both make sense. The one proposed by Gert is stitching of an ODU4 and ODUC1, while the one you are describing is tunneling of ODU4 over an ODUC1 trail.
They both seems reasonable to me, why the stitching is not feasible?

Cheers
Daniele

From: CCAMP [mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: giovedì 17 novembre 2016 17:06
To: [email-masked]
Subject: Re: [CCAMP] ODU4 and ODUCn discussion

Hello Gert,

Instead of:

1.      A use case to consider is:

It should be:

Regards, Huub.

--

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 18 Nov 2016 19:30:54 +0100

Daniele,

You write:

You're welcome.

I see two different use cases that both make
sense.

I have to disagree (again).

The one proposed by Gert is stitching of an
ODU4 and ODUC1,

This use case is impossible. As you can see in G.709 (2016) figure
7-1

a lower order ODU4 is mapped into a higher order ODUC1, and this

means that they constitute different layers in the OTN.

And are impossible to stitch.

while the one you are describing is tunneling
of ODU4 over an ODUC1 trail.

Correct.

They both seems reasonable to me, why the
stitching is not feasible?

I tried to explain above.

Best regards, Huub.

From:
CCAMP [mailto:[email-masked]]
On Behalf Of Huub van Helvoort

To: [email-masked]

Hello
Gert,

Instead of:

1.

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

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

NE1
NE2 (=GW-NE)                       NE3

It should be:

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

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

NE1                    NE2
(=GW-NE)                       NE3

Regards, Huub.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 18 Nov 2016 19:02:55 +0000

Thank Huub,

Authors, if you could have a little piece of text describing this consideration in the framework or in one of the solution documents (depending what are the plans for the merge) that would be great.

Thanks
Daniele

From: Huub van Helvoort [mailto:[email-masked]]
Sent: venerdì 18 novembre 2016 19:31
To: Daniele Ceccarelli <[email-masked]>; [email-masked]
Subject: Re: [CCAMP] ODU4 and ODUCn discussion

Daniele,

You write:

You're welcome.

I see two different use cases that both make sense.

The one proposed by Gert is stitching of an ODU4 and ODUC1,

This use case is impossible. As you can see in G.709 (2016) figure 7-1
a lower order ODU4 is mapped into a higher order ODUC1, and this
means that they constitute different layers in the OTN.
And are impossible to stitch.

while the one you are describing is tunneling of ODU4 over an ODUC1 trail.

Correct.

Best regards, Huub.

From: CCAMP [mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: giovedì 17 novembre 2016 17:06
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] ODU4 and ODUCn discussion

Hello Gert,

Instead of:

It should be:

Regards, Huub.

--

---

From: Iftekhar Hussain <[email-masked]>
Date: Mon, 21 Nov 2016 02:02:20 +0000

Agree with that it is important to clarify the scope of the proposed solution (e.g. include some use cases). Ideally this sort of info should be in framework doc.

Also is just specifying the signal type code points sufficient for the overall GMPLS RSVP-TE signaling solution for Beyond 100G or it would require additional  info (e.g., multiplexing structure as in RFC4328 and RFC7139)?

Thanks,
Iftekhar

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Friday, November 18, 2016 11:03 AM
To: [email-masked]; [email-masked]
Subject: Re: [CCAMP] ODU4 and ODUCn discussion

Thank Huub,

Thanks
Daniele

From: Huub van Helvoort [mailto:[email-masked]]
Sent: venerdì 18 novembre 2016 19:31
To: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] ODU4 and ODUCn discussion

Daniele,

You write:

You're welcome.

Correct.

Best regards, Huub.

Hello Gert,

Instead of:

It should be:

Regards, Huub.

--

---

From: [email-masked]
Date: Mon, 21 Nov 2016 17:30:48 +0800

Thank Daniele for your suggestion. We will add text to describe the 
consideration.
I think we authors need to do a thorough evaluation of ODUCn and submit a 
new version to clarify the confusion before next IETF meeting.

And also we will split the solution into separate documents base on your 
suggestion.

Thanks
Qilei

Daniele Ceccarelli <[email-masked]> 
发件人:  "CCAMP" <[email-masked]>
2016/11/19 03:02

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

主题

Thank Huub,
 
Authors, if you could have a little piece of text describing this 
consideration in the framework or in one of the solution documents 
(depending what are the plans for the merge) that would be great.
 
Thanks
Daniele 

Daniele,

You write:

You're welcome.

Correct.

Best regards, Huub.

 
Hello Gert,

Instead of:

It should be: 

             NE1                    NE2 (=GW-NE)                       NE3

---

From: Gert Grammel <[email-masked]>
Date: Wed, 23 Nov 2016 13:01:00 +0000

Daniele, Authors,

After our initial email exchange I took a more detailed look in the 2016 version of G.709. In essence, the 2016 version of G.709 would impact control plane work for G.709 (RFC7139) as well as for WSON (RFC6163). The complex nature of those definitions will certainly not be an easy-going extension as it had been envisaged so far. Writing a “little piece of text” looks to me like a “little bit of understatement”. If the WG intends to work on the subject, my pledge would be to start from a framework document to capture the new concepts before defining protocol extensions.

Best

Gert

Below a list of observations that influenced this view:

1.       OPUCn, ODUCn and OTUCn are new and the layering relationship to the former structure is a bit surprising, as the discussion on the list (see below) showed. Better to get this right early on

2.       Figure 7-1 shows the OTN multiplexing and mapping structures but does not indicate how e.g. a 400GE would be mapped into this structure. It is not surprising as 400GE is still in the makings, but raises a few questions about how it is planned to be mapped. However guidance from SG15 would help to get the protocol architecture future proof.

a.       Does every client signal need to be wrapped into an OPUk/ODUk before it can be transported via an OPUCn/ODUCn? --> this would mean to extend the ODU structure by an ODU5,6,7 etc. for clients > 100G

b.       Will only client signals <= 100G need to be wrapped in an OPUk/ODUk before it can be transported via an OPUCn/ODUCn? --> this would mean that there will be a break in the mappings at about 100G signals and no ODU5,6,7 would need to be defined

c.       Will future clients be mapped directly into OPUCn/ODUCn and the special case of 100GE-->OPUk/ODUk-->OPUCn/ODUCn will become just another option? (Note: the figure explicitly allows for proprietary mappings directly into OPUCn/ODUCn which looks like a practical use case, but it looks odd that it remains prorietary)

3.       The section “7.1 Mapping” and “7.2 Wavelength Division Multiplex” changed a bit from the 2012 version. As acronyms have changed too, a 1:1 comparison is not too simple. The takeaway is that an OTU can be mapped into a single wavelength or spread across some (OTLk.n and OTLC.n) which means inverse multiplexing. So far this case has not been considered in RFC7139 or RFC6163.

4.       In Section “6.1.1 OTN digital structure” it is explained that an OTUk contains a FEC, but OTUCn does not, leaving it to the interface to apply some. This basically creates a FEC layer below the OTUCn that will not be defined in G.709. A control plane would need to check compatibility of wavelength, modulation, interfaces (i.e. how many lanes) and compatibility of FEC, as well as usage of OTUk vs OTUCn. Also this case has not been considered in RFC7139 or RFC6163.

5.       There is also a new OMS MSI (sect 15.4) overhead defined, which provides a list of OCh and OTSiA frequency slot,port numbers and a list of media channels (frequency slot, media channel port numbers) to decode the lanes correctly. This may affect RFC6163

6.       The term “Wavelength Division Multiplex” in the sections above doesn’t imply a wavelength can be routed through a DWDM network since we know that e.g. 100G interfaces are not yet defined by SG15 for amplified DWDM applications. Without amplifiers, the distance supported by such DWDM is likely limited to below 80-100km. It is not yet clear by when this limitation will be lifted by SG15 (see draft-many-coherent-dwdm-if-control-00). After all, OTU4 based 100G interfaces for amplified DWDM applications are available and have even been proven to be interoperable among multiple vendors covering distances >1000km.  However, to stay in the standards framework for now, RFC6163 would need to consider:

a.       While a OTUCn can be digitally constructed and mapped into a single wavelength, it cannot be routed in WSON --> no 100G interfaces in amplified DWDM networks defined in G.698.2

b.       An OTUCn may be broken down into 4 lanes at 25G (OTL4.4) but still can’t be routed in WSON --> no 25G interfaces in amplified DWDM networks defined in G.698.2

c.       An OTU3 (=40G) can be broken down in OTL3.4 providing 4 lanes at 10G each --> 10G interfaces are allowed in amplified DWDM networks defined in G.698.2

From: CCAMP <[email-masked]> on behalf of Daniele Ceccarelli <[email-masked]>
Date: Friday 18 November 2016 at 20:02
To: "[email-masked]" <[email-masked]>, CCAMP <[email-masked]>
Subject: Re: [CCAMP] ODU4 and ODUCn discussion

Thank Huub,

Thanks
Daniele

Daniele,

You write:

You're welcome.

Correct.

Best regards, Huub.

Hello Gert,

Instead of:

It should be:

Regards, Huub.

--

---

From: [email-masked]
Date: Wed, 23 Nov 2016 23:38:58 +0800

Hi Gert,

Thanks for your comments. Following is my answer to your previous mail and 
this one.

(1), About the questions in your previous mail. I think you already have 
many of them solved. ODUCn has almost the same overhead as that of ODUk, 
so I don't think some mechanisms of ODUCn (e.g., OAM etc) differ from 
those of ODUk. In the ODUCn draft, I think we should mainly pay attention 
to ODUCn's feature and its difference with ODUk now, such as layer model 
of ODUCn and setup of ODUCn connection.

(2), About the questions in the second items of this thread. I think it's 
out of the scope of CCAMP. I can't give a definite answer to these 
questions. 

(3), Control of optical network is out of the scope of current ODUCn 
document. We will not involve this part in. Also I suggest you take a look 
at RFC7698, which mainly focus on the control of flexible grid network.

Thanks
Qilei

2016/11/23 21:01

收件人
Daniele Ceccarelli <[email-masked]>, "[email-masked]" 
<[email-masked]>, 
抄送
"[email-masked]" <[email-masked]>
主题
Re: [CCAMP] ODU4 and ODUCn discussion

Daniele, Authors,
 
After our initial email exchange I took a more detailed look in the 2016 
version of G.709. In essence, the 2016 version of G.709 would impact 
control plane work for G.709 (RFC7139) as well as for WSON (RFC6163). The 
complex nature of those definitions will certainly not be an easy-going 
extension as it had been envisaged so far. Writing a “little piece of 
text” looks to me like a “little bit of understatement”. If the WG 
intends to work on the subject, my pledge would be to start from a 
framework document to capture the new concepts before defining protocol 
extensions.
 
Best
 
Gert

Below a list of observations that influenced this view:
1.       OPUCn, ODUCn and OTUCn are new and the layering relationship to 
the former structure is a bit surprising, as the discussion on the list 
(see below) showed. Better to get this right early on
2.       Figure 7-1 shows the OTN multiplexing and mapping structures but 
does not indicate how e.g. a 400GE would be mapped into this structure. It 
is not surprising as 400GE is still in the makings, but raises a few 
questions about how it is planned to be mapped. However guidance from SG15 
would help to get the protocol architecture future proof.
a.       Does every client signal need to be wrapped into an OPUk/ODUk 
before it can be transported via an OPUCn/ODUCn? à this would mean to 
extend the ODU structure by an ODU5,6,7 etc. for clients > 100G
b.       Will only client signals <= 100G need to be wrapped in an 
OPUk/ODUk before it can be transported via an OPUCn/ODUCn? à this would 
mean that there will be a break in the mappings at about 100G signals and 
no ODU5,6,7 would need to be defined
c.       Will future clients be mapped directly into OPUCn/ODUCn and the 
special case of 100GEàOPUk/ODUkàOPUCn/ODUCn will become just another 
option? (Note: the figure explicitly allows for proprietary mappings 
directly into OPUCn/ODUCn which looks like a practical use case, but it 
looks odd that it remains prorietary)
3.       The section “7.1 Mapping” and “7.2 Wavelength Division 
Multiplex” changed a bit from the 2012 version. As acronyms have changed 
too, a 1:1 comparison is not too simple. The takeaway is that an OTU can 
be mapped into a single wavelength or spread across some (OTLk.n and 
OTLC.n) which means inverse multiplexing. So far this case has not been 
considered in RFC7139 or RFC6163.
4.       In Section “6.1.1 OTN digital structure” it is explained that 
an OTUk contains a FEC, but OTUCn does not, leaving it to the interface to 
apply some. This basically creates a FEC layer below the OTUCn that will 
not be defined in G.709. A control plane would need to check compatibility 
of wavelength, modulation, interfaces (i.e. how many lanes) and 
compatibility of FEC, as well as usage of OTUk vs OTUCn. Also this case 
has not been considered in RFC7139 or RFC6163.
5.       There is also a new OMS MSI (sect 15.4) overhead defined, which 
provides a list of OCh and OTSiA frequency slot,port numbers and a list of 
media channels (frequency slot, media channel port numbers) to decode the 
lanes correctly. This may affect RFC6163
6.       The term “Wavelength Division Multiplex” in the sections above 
doesn’t imply a wavelength can be routed through a DWDM network since we 
know that e.g. 100G interfaces are not yet defined by SG15 for amplified 
DWDM applications. Without amplifiers, the distance supported by such DWDM 
is likely limited to below 80-100km. It is not yet clear by when this 
limitation will be lifted by SG15 (see 
draft-many-coherent-dwdm-if-control-00). After all, OTU4 based 100G 
interfaces for amplified DWDM applications are available and have even 
been proven to be interoperable among multiple vendors covering distances 
>1000km.  However, to stay in the standards framework for now, RFC6163 
would need to consider:
a.       While a OTUCn can be digitally constructed and mapped into a 
single wavelength, it cannot be routed in WSON à no 100G interfaces in 
amplified DWDM networks defined in G.698.2
b.       An OTUCn may be broken down into 4 lanes at 25G (OTL4.4) but 
still can’t be routed in WSON à no 25G interfaces in amplified DWDM 
networks defined in G.698.2
c.       An OTU3 (=40G) can be broken down in OTL3.4 providing 4 lanes at 
10G each à 10G interfaces are allowed in amplified DWDM networks defined 
in G.698.2

 
From: CCAMP <[email-masked]> on behalf of Daniele Ceccarelli 
<[email-masked]>
Date: Friday 18 November 2016 at 20:02
To: "[email-masked]" <[email-masked]>, CCAMP <[email-masked]>
Subject: Re: [CCAMP] ODU4 and ODUCn discussion
 
Thank Huub,

Thanks
Daniele 

Daniele,

You write:

You're welcome.

Correct.

Best regards, Huub.

 
Hello Gert,

Instead of:

It should be: 

             NE1                    NE2 (=GW-NE)                       NE3

---

From: Dieter Beller <[email-masked]>
Date: Wed, 23 Nov 2016 17:50:10 +0100

Hi all,

I would submit that we need a document similar to RFC
7139 (GMPLS Signaling Extensions for Control of Evolving
G.709 Optical Transport

Networks) for the new ODUCn signal types.

RFC 7139
contains sufficient information and descriptions regaqrding the new
G.709 signal types introduced in the Feb 2012 revision of G.709.

I don't think we need to take a different approach for the latest
2016 evolution of G.709.

Thanks,

Dieter

On 23.11.2016 16:38,
[email-masked] wrote:

Hi Gert,

Thanks for your comments.
Following
is my answer to your previous mail and this one.

(1), About the questions in your
previous
mail. I think you already have many of them solved. ODUCn has
almost the
same overhead as that of ODUk, so I don't think some mechanisms
of ODUCn
(e.g., OAM etc) differ from those of ODUk. In the ODUCn draft, I
think
we should mainly pay attention to ODUCn's feature and its
difference with
ODUk now, such as layer model of ODUCn and setup of ODUCn
connection.

(2), About the questions in the
second
items of this thread. I think it's out of the scope of CCAMP. I
can't give
a definite answer to these questions.

(3), Control of optical network
is out
of the scope of current ODUCn document. We will not involve this
part in.
Also I suggest you take a look at RFC7698, which mainly focus on
the control
of flexible grid network.

Thanks

Qilei

Gert
Grammel <[email-masked]>

发件人:  "CCAMP"
<[email-masked]>

2016/11/23 21:01

收件人

Daniele
Ceccarelli
<[email-masked]>,
"[email-masked]" <[email-masked]>,

抄送

"[email-masked]"
<[email-masked]>

主题

Re: [CCAMP]
ODU4 and ODUCn discussion

Daniele, Authors,

After our initial email exchange I
took
a more detailed look in the 2016 version of G.709. In essence,
the 2016
version of G.709 would impact control plane work for G.709
(RFC7139) as
well as for WSON (RFC6163). The complex nature of those
definitions will
certainly not be an easy-going extension as it had been
envisaged so far.
Writing a “little piece of text” looks to me like a “little bit
of
understatement”. If the WG intends to work on the subject, my
pledge
would be to start from a framework document to capture the new
concepts
before defining protocol extensions.

Best

Gert

Below a list of observations that
influenced
this view:

1.       OPUCn, ODUCn and
OTUCn are new and the layering relationship to the former
structure is
a bit surprising, as the discussion on the list (see below)
showed. Better
to get this right early on

2.       Figure 7-1 shows
the OTN multiplexing and mapping structures but does not
indicate how e.g.
a 400GE would be mapped into this structure. It is not
surprising as 400GE
is still in the makings, but raises a few questions about how it
is planned
to be mapped. However guidance from SG15 would help to get the
protocol
architecture future proof.

a.       Does every client
signal need to be wrapped into an OPUk/ODUk before it can be
transported
via an OPUCn/ODUCn? →
this would mean to extend the ODU structure by an ODU5,6,7 etc.
for clients
> 100G

b.       Will only client
signals <= 100G need to be wrapped in an OPUk/ODUk before it
can be
transported via an OPUCn/ODUCn? →
this would mean that there will be a break in the mappings at
about 100G
signals and no ODU5,6,7 would need to be defined

c.       Will future clients
be mapped directly into OPUCn/ODUCn and the special case of
100GE→OPUk/ODUk→OPUCn/ODUCn
will become just another option? (Note: the figure explicitly
allows for
proprietary mappings directly into OPUCn/ODUCn which looks like
a practical
use case, but it looks odd that it remains prorietary)

3.       The section “7.1
Mapping” and “7.2 Wavelength Division Multiplex” changed a bit
from
the 2012 version. As acronyms have changed too, a 1:1 comparison
is not
too simple. The takeaway is that an OTU can be mapped into a
single wavelength
or spread across some (OTLk.n and OTLC.n) which means inverse
multiplexing.
So far this case has not been considered in RFC7139 or RFC6163.

4.       In Section “6.1.1
OTN digital structure” it is explained that an OTUk contains a
FEC, but
OTUCn does not, leaving it to the interface to apply some. This
basically
creates a FEC layer below the OTUCn that will not be defined in
G.709.
A control plane would need to check compatibility of wavelength,
modulation,
interfaces (i.e. how many lanes) and compatibility of FEC, as
well as usage
of OTUk vs OTUCn. Also this case has not been considered in
RFC7139 or
RFC6163.

5.       There is also a
new OMS MSI (sect 15.4) overhead defined, which provides a list
of OCh
and OTSiA frequency slot,port numbers and a list of media
channels (frequency
slot, media channel port numbers) to decode the lanes correctly.
This may
affect RFC6163

6.       The term “Wavelength
Division Multiplex” in the sections above doesn’t imply a
wavelength
can be routed through a DWDM network since we know that e.g.
100G interfaces
are not yet defined by SG15 for amplified DWDM applications.
Without amplifiers,
the distance supported by such DWDM is likely limited to below
80-100km.
It is not yet clear by when this limitation will be lifted by
SG15 (see
draft-many-coherent-dwdm-if-control-00). After all, OTU4 based
100G interfaces
for amplified DWDM applications are available and have even been
proven
to be interoperable among multiple vendors covering distances
>1000km.
However, to stay in the standards framework for now, RFC6163
would
need to consider:

a.       While a OTUCn can
be digitally constructed and mapped into a single wavelength, it
cannot
be routed in WSON →
no 100G interfaces in amplified DWDM networks defined in G.698.2

b.       An OTUCn may be
broken down into 4 lanes at 25G (OTL4.4) but still can’t be
routed in
WSON →
no 25G interfaces in amplified DWDM networks defined in G.698.2

c.       An OTU3 (=40G)
can be broken down in OTL3.4 providing 4 lanes at 10G each →
10G interfaces are allowed in amplified DWDM networks defined in
G.698.2

From: CCAMP
<[email-masked]>
on behalf of Daniele Ceccarelli
<[email-masked]>

To: "[email-masked]" <[email-masked]>,
CCAMP <[email-masked]>

Thank Huub,

Authors, if you could have a little
piece
of text describing this consideration in the framework or in one
of the
solution documents (depending what are the plans for the merge)
that would
be great.

Thanks

Daniele

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

Daniele,

You write:

Thanks for the clear explanation
Huub.

You're welcome.

I see two different use cases that
both
make sense.

The one proposed by Gert is
stitching of
an ODU4 and ODUC1,

This use case is impossible. As you can see in G.709 (2016)
figure 7-1

while the one you are describing is
tunneling
of ODU4 over an ODUC1 trail.

Correct.

They both seems reasonable to me,
why the
stitching is not feasible?

Best regards, Huub.

From: CCAMP [mailto:[email-masked]]
On Behalf Of Huub van Helvoort

To: [email-masked]

Hello Gert,

Instead of:

1.      A
use case to consider is:

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

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

NE1
NE2 (=GW-NE)
NE3

It should be:

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

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

NE1
NE2 (=GW-NE)
NE3

Regards, Huub.

--

Always remember that you are
unique...just
like everyone else..._______________________________________________

CCAMP mailing list

[email-masked]

---

From: Gert Grammel <[email-masked]>
Date: Wed, 23 Nov 2016 18:52:26 +0000

Hi Dieter, Qilei

don’t forget to add the OTUCn signal types (OTU4 was included in RFC 7139<https://tools.ietf.org/html/rfc7139>) and additional mappings into ODUCn/OTUCn and consider how to signal the FEC which is now found outside OTUCn …

The important part is that the subtle differences are well understood and taken care of. Narrowing down the discussion into “how to signal ODUCn” appears to me as over-simplification. Case in point, Qilei mentioned RFC7698 which is a framework that became necessary because of flexgrid and multi-lane interfaces. I find RFC7698 quite beneficial and feel a similar framework document would be needed on the digital part once flexible sized OTUCn and ODUCn are introduced, while swapping FEC out of the OTU definition.

If you think you can cover everything in extending non-framework documents, feel free to go ahead. We will see over time whether lacking the framework will burden the progress.

Gert

From: Dieter Beller <[email-masked]>
Organization: Nokia
Date: Wednesday 23 November 2016 at 17:50
To: "[email-masked]" <[email-masked]>, Gert Grammel <[email-masked]>
Cc: CCAMP <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [CCAMP] ODU4 and ODUCn discussion

Hi all,

I would submit that we need a document similar to RFC 7139<https://tools.ietf.org/html/rfc7139> (GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport
Networks) for the new ODUCn signal types.

RFC 7139<https://tools.ietf.org/html/rfc7139> contains sufficient information and descriptions regaqrding the new G.709 signal types introduced in the Feb 2012 revision of G.709.

I don't think we need to take a different approach for the latest 2016 evolution of G.709.

Thanks,
Dieter
On 23.11.2016 16:38, [email-masked]<mailto:[email-masked]> wrote:
Hi Gert,

Thanks for your comments. Following is my answer to your previous mail and this one.

(1), About the questions in your previous mail. I think you already have many of them solved. ODUCn has almost the same overhead as that of ODUk, so I don't think some mechanisms of ODUCn (e.g., OAM etc) differ from those of ODUk. In the ODUCn draft, I think we should mainly pay attention to ODUCn's feature and its difference with ODUk now, such as layer model of ODUCn and setup of ODUCn connection.

(2), About the questions in the second items of this thread. I think it's out of the scope of CCAMP. I can't give a definite answer to these questions.

(3), Control of optical network is out of the scope of current ODUCn document. We will not involve this part in. Also I suggest you take a look at RFC7698, which mainly focus on the control of flexible grid network.

Thanks
Qilei

Gert Grammel <[email-masked]><mailto:[email-masked]>
发件人:  "CCAMP" <[email-masked]><mailto:[email-masked]>

2016/11/23 21:01

收件人

Daniele Ceccarelli <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>,

抄送

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

主题

Daniele, Authors,

Best

Gert

Below a list of observations that influenced this view:
1.       OPUCn, ODUCn and OTUCn are new and the layering relationship to the former structure is a bit surprising, as the discussion on the list (see below) showed. Better to get this right early on
2.       Figure 7-1 shows the OTN multiplexing and mapping structures but does not indicate how e.g. a 400GE would be mapped into this structure. It is not surprising as 400GE is still in the makings, but raises a few questions about how it is planned to be mapped. However guidance from SG15 would help to get the protocol architecture future proof.
a.       Does every client signal need to be wrapped into an OPUk/ODUk before it can be transported via an OPUCn/ODUCn? → this would mean to extend the ODU structure by an ODU5,6,7 etc. for clients > 100G
b.       Will only client signals <= 100G need to be wrapped in an OPUk/ODUk before it can be transported via an OPUCn/ODUCn? → this would mean that there will be a break in the mappings at about 100G signals and no ODU5,6,7 would need to be defined
c.       Will future clients be mapped directly into OPUCn/ODUCn and the special case of 100GE→OPUk/ODUk→OPUCn/ODUCn will become just another option? (Note: the figure explicitly allows for proprietary mappings directly into OPUCn/ODUCn which looks like a practical use case, but it looks odd that it remains prorietary)
3.       The section “7.1 Mapping” and “7.2 Wavelength Division Multiplex” changed a bit from the 2012 version. As acronyms have changed too, a 1:1 comparison is not too simple. The takeaway is that an OTU can be mapped into a single wavelength or spread across some (OTLk.n and OTLC.n) which means inverse multiplexing. So far this case has not been considered in RFC7139 or RFC6163.
4.       In Section “6.1.1 OTN digital structure” it is explained that an OTUk contains a FEC, but OTUCn does not, leaving it to the interface to apply some. This basically creates a FEC layer below the OTUCn that will not be defined in G.709. A control plane would need to check compatibility of wavelength, modulation, interfaces (i.e. how many lanes) and compatibility of FEC, as well as usage of OTUk vs OTUCn. Also this case has not been considered in RFC7139 or RFC6163.
5.       There is also a new OMS MSI (sect 15.4) overhead defined, which provides a list of OCh and OTSiA frequency slot,port numbers and a list of media channels (frequency slot, media channel port numbers) to decode the lanes correctly. This may affect RFC6163
6.       The term “Wavelength Division Multiplex” in the sections above doesn’t imply a wavelength can be routed through a DWDM network since we know that e.g. 100G interfaces are not yet defined by SG15 for amplified DWDM applications. Without amplifiers, the distance supported by such DWDM is likely limited to below 80-100km. It is not yet clear by when this limitation will be lifted by SG15 (see draft-many-coherent-dwdm-if-control-00). After all, OTU4 based 100G interfaces for amplified DWDM applications are available and have even been proven to be interoperable among multiple vendors covering distances >1000km.  However, to stay in the standards framework for now, RFC6163 would need to consider:
a.       While a OTUCn can be digitally constructed and mapped into a single wavelength, it cannot be routed in WSON → no 100G interfaces in amplified DWDM networks defined in G.698.2
b.       An OTUCn may be broken down into 4 lanes at 25G (OTL4.4) but still can’t be routed in WSON → no 25G interfaces in amplified DWDM networks defined in G.698.2
c.       An OTU3 (=40G) can be broken down in OTL3.4 providing 4 lanes at 10G each → 10G interfaces are allowed in amplified DWDM networks defined in G.698.2

From: CCAMP <[email-masked]><mailto:[email-masked]> on behalf of Daniele Ceccarelli <[email-masked]><mailto:[email-masked]>
Date: Friday 18 November 2016 at 20:02
To: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, CCAMP <[email-masked]><mailto:[email-masked]>
Subject: Re: [CCAMP] ODU4 and ODUCn discussion

Thank Huub,

Thanks
Daniele

From: Huub van Helvoort [mailto:[email-masked]]
Sent: venerdì 18 novembre 2016 19:31
To: Daniele Ceccarelli <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] ODU4 and ODUCn discussion

Daniele,

You write:

You're welcome.

Correct.

Best regards, Huub.

Hello Gert,

Instead of:

It should be:

Regards, Huub.

--
================================================================
Always remember that you are unique...just like everyone else..._______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp

CCAMP mailing list

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

---

From: Gert Grammel <[email-masked]>
Date: Wed, 23 Nov 2016 19:00:41 +0000

Qilei,

My last email contained a few observations that were intended to allow fellow ccamp-ers to follow what the discussion is about. I did not expect feedback on those but rather if folks feel a framework is the right thing to do or not. Your opinion about this subject is welcomed

Gert

From: "[email-masked]" <[email-masked]>
Date: Wednesday 23 November 2016 at 16:38
To: Gert Grammel <[email-masked]>
Cc: CCAMP <[email-masked]>, Daniele Ceccarelli <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [CCAMP] ODU4 and ODUCn discussion

Hi Gert,

Thanks
Qilei

2016/11/23 21:01

收件人

Daniele Ceccarelli <[email-masked]>, "[email-masked]" <[email-masked]>,

抄送

主题

Daniele, Authors,

Best

Gert

Thank Huub,

Thanks
Daniele

Daniele,

You write:

You're welcome.

Correct.

Best regards, Huub.

Hello Gert,

Instead of:

It should be:

Regards, Huub.

---

From: Iftekhar Hussain <[email-masked]>
Date: Wed, 23 Nov 2016 21:57:47 +0000

Yes, agree it should leverage RFC 7139 as much as possible and follow similar approach.  To begin with should start with use cases, requirements, and necessary solutions (GMPLS signaling and required extension).

Iftekhar
From: Dieter Beller [mailto:[email-masked]]
Sent: Wednesday, November 23, 2016 8:50 AM
To: [email-masked]; Gert Grammel
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] ODU4 and ODUCn discussion

Hi all,

Thanks,
Dieter

Thanks
Qilei

2016/11/23 21:01

收件人

抄送

主题

Daniele, Authors,

Best

Gert

Thank Huub,

Thanks
Daniele

Daniele,

You write:

You're welcome.

Correct.

Best regards, Huub.

Hello Gert,

Instead of:

It should be:

Regards, Huub.

CCAMP mailing list

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Thu, 24 Nov 2016 05:55:06 +0000

Hi, Gert,

     Yes;  starting with understanding the new features of the new OTN before diving into the protocol extensions is definitely the usual CCAMP style, ☺.   So, we should not look at RFC7139 which is protocol extension RFC, but rather RFC7062.

Regards,
Xian

发件人: CCAMP [mailto:[email-masked]] 代表 Gert Grammel
发送时间: 2016年11月23日 21:01
收件人: Daniele Ceccarelli; [email-masked]
抄送: [email-masked]
主题: Re: [CCAMP] ODU4 and ODUCn discussion

Daniele, Authors,

Best

Gert

From: CCAMP <[email-masked]<mailto:[email-masked]>> on behalf of Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>
Date: Friday 18 November 2016 at 20:02
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, CCAMP <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] ODU4 and ODUCn discussion

Thank Huub,

Thanks
Daniele

Daniele,

You write:

You're welcome.

Correct.

Best regards, Huub.

Hello Gert,

Instead of:

It should be:

Regards, Huub.

--

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 24 Nov 2016 09:07:32 +0100

+1

Regards, Huub.

------

On 23/11/2016 17:50, Dieter Beller wrote:

Hi all,

I would submit that we need a document similar to RFC 7139 (GMPLS
Signaling Extensions for Control of Evolving G.709 Optical
Transport

RFC 7139
contains sufficient information and descriptions regaqrding the
new G.709 signal types introduced in the Feb 2012 revision of
G.709.

Thanks,

Dieter

On 23.11.2016 16:38, [email-masked]
wrote:

Hi Gert,

Thanks for your comments.
Following is my answer to your previous mail and this one.

(1), About the questions in
your previous mail. I think you already have many of them
solved. ODUCn has almost the same overhead as that of ODUk, so
I don't think some mechanisms of ODUCn (e.g., OAM etc) differ
from those of ODUk. In the ODUCn draft, I think we should
mainly pay attention to ODUCn's feature and its difference
with ODUk now, such as layer model of ODUCn and setup of ODUCn
connection.

(2), About the questions in the
second items of this thread. I think it's out of the scope of
CCAMP. I can't give a definite answer to these questions.

(3), Control of optical network
is out of the scope of current ODUCn document. We will not
involve this part in. Also I suggest you take a look at
RFC7698, which mainly focus on the control of flexible grid
network.

Thanks

Qilei

Gert

2016/11/23 21:01

收件人

Daniele
Ceccarelli <[email-masked]>,
"[email-masked]"
<[email-masked]>,

抄送

"[email-masked]"
<[email-masked]>

主题

Re: [CCAMP]

Daniele, Authors,

After our initial email exchange I
took a more detailed look in the 2016 version of G.709. In
essence, the 2016 version of G.709 would impact control plane
work for G.709 (RFC7139) as well as for WSON (RFC6163). The
complex nature of those definitions will certainly not be an
easy-going extension as it had been envisaged so far. Writing
a “little piece of text” looks to me like a “little bit of
understatement”. If the WG intends to work on the subject, my
pledge would be to start from a framework document to capture
the new concepts before defining protocol extensions.

Best

Gert

influenced this view:

1.       OPUCn, ODUCn and OTUCn
are new and the layering relationship to the former structure
is a bit surprising, as the discussion on the list (see below)
showed. Better to get this right early on

2.       Figure 7-1 shows the OTN
multiplexing and mapping structures but does not indicate how
e.g. a 400GE would be mapped into this structure. It is not
surprising as 400GE is still in the makings, but raises a few
questions about how it is planned to be mapped. However
guidance from SG15 would help to get the protocol architecture
future proof.

a.       Does every client signal
need to be wrapped into an OPUk/ODUk before it can be
transported via an OPUCn/ODUCn? → this would mean to extend the ODU structure by an
ODU5,6,7 etc. for clients > 100G

b.       Will only client signals
<= 100G need to be wrapped in an OPUk/ODUk before it can be
transported via an OPUCn/ODUCn? → this would mean that there will be a break in the
mappings at about 100G signals and no ODU5,6,7 would need to
be defined

c.       Will future clients be
mapped directly into OPUCn/ODUCn and the special case of 100GE→OPUk/ODUk→OPUCn/ODUCn will become just another
option? (Note: the figure explicitly allows for proprietary
mappings directly into OPUCn/ODUCn which looks like a
practical use case, but it looks odd that it remains
prorietary)

3.       The section “7.1 Mapping”
and “7.2 Wavelength Division Multiplex” changed a bit from the
2012 version. As acronyms have changed too, a 1:1 comparison
is not too simple. The takeaway is that an OTU can be mapped
into a single wavelength or spread across some (OTLk.n and
OTLC.n) which means inverse multiplexing. So far this case has
not been considered in RFC7139 or RFC6163.

4.       In Section “6.1.1 OTN
digital structure” it is explained that an OTUk contains a
FEC, but OTUCn does not, leaving it to the interface to apply
some. This basically creates a FEC layer below the OTUCn that
will not be defined in G.709. A control plane would need to
check compatibility of wavelength, modulation, interfaces
(i.e. how many lanes) and compatibility of FEC, as well as
usage of OTUk vs OTUCn. Also this case has not been considered
in RFC7139 or RFC6163.

5.       There is also a new OMS
MSI (sect 15.4) overhead defined, which provides a list of OCh
and OTSiA frequency slot,port numbers and a list of media
channels (frequency slot, media channel port numbers) to
decode the lanes correctly. This may affect RFC6163

6.       The term “Wavelength
Division Multiplex” in the sections above doesn’t imply a
wavelength can be routed through a DWDM network since we know
that e.g. 100G interfaces are not yet defined by SG15 for
amplified DWDM applications. Without amplifiers, the distance
supported by such DWDM is likely limited to below 80-100km. It
is not yet clear by when this limitation will be lifted by
SG15 (see draft-many-coherent-dwdm-if-control-00). After all,
OTU4 based 100G interfaces for amplified DWDM applications are
available and have even been proven to be interoperable among
multiple vendors covering distances >1000km.  However, to
stay in the standards framework for now, RFC6163 would need to
consider:

a.       While a OTUCn can be
digitally constructed and mapped into a single wavelength, it
cannot be routed in WSON → no 100G interfaces in amplified DWDM
networks defined in G.698.2

b.       An OTUCn may be broken
down into 4 lanes at 25G (OTL4.4) but still can’t be routed in
WSON → no 25G interfaces in amplified DWDM
networks defined in G.698.2

c.       An OTU3 (=40G) can be
broken down in OTL3.4 providing 4 lanes at 10G each → 10G interfaces are allowed in amplified DWDM
networks defined in G.698.2

From: CCAMP <[email-masked]>
on behalf of Daniele Ceccarelli <[email-masked]>

Thank Huub,

Authors, if you could have a
little piece of text describing this consideration in the
framework or in one of the solution documents (depending what
are the plans for the merge) that would be great.

Thanks

Daniele

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

Daniele,

You write:

You're welcome.

both make sense.

The one proposed by Gert is
stitching of an ODU4 and ODUC1,

a lower order ODU4 is mapped into a higher order ODUC1, and
this

while the one you are describing
is tunneling of ODU4 over an ODUC1 trail.

Correct.

They both seems reasonable to me,
why the stitching is not feasible?

Best regards, Huub.

From: CCAMP [mailto:[email-masked]] On Behalf Of Huub van
Helvoort

To: [email-masked]

Hello Gert,

Instead of:

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

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

NE1
NE2 (=GW-NE)                       NE3

It should be:

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

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

NE1
NE2 (=GW-NE)                       NE3

Regards, Huub.

--

Always remember that you are
unique...just like everyone else..._______________________________________________

CCAMP mailing list

[email-masked]

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 28 Nov 2016 14:51:10 +0000

All,

It’s great to see such an enthusiasm in this new topic.

We’re contribution driven, if you feel the need to submit separate framework and encoding drafts please do so, on the other hand if you think that an encoding document with an explaining intro is ok, that’s fine too.
Let’s see what comes out and then we’ll decide what and how to adopt in the working group.

Once again I would like to remind that the new IESG statement doesn’t mean that we no longer need support documentation, it’s just that I might be managed differently.

Thanks
Daniele

From: CCAMP [mailto:[email-masked]] On Behalf Of Iftekhar Hussain
Sent: mercoledì 23 novembre 2016 22:58
To: Dieter Beller <[email-masked]>; [email-masked]; Gert Grammel <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] ODU4 and ODUCn discussion

Iftekhar
From: Dieter Beller [mailto:[email-masked]]
Sent: Wednesday, November 23, 2016 8:50 AM
To: [email-masked]<mailto:[email-masked]>; Gert Grammel
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] ODU4 and ODUCn discussion

Hi all,

Thanks,
Dieter

Thanks
Qilei

2016/11/23 21:01

收件人

抄送

主题

Daniele, Authors,

Best

Gert

Thank Huub,

Thanks
Daniele

Daniele,

You write:

You're welcome.

Correct.

Best regards, Huub.

Hello Gert,

Instead of:

It should be:

Regards, Huub.

CCAMP mailing list