Subject: [CCAMP] Closing G.709 open issues

From: Lou Berger <[email-masked]>
Date: Wed, 08 May 2013 12:52:41 -0400

Authors/WG,
	I think all would like to wrap up the 709 documents before
Berlin.  To do this we need to:
1) Ensure all discussed points have been resolved
2) Hold a 2nd LC to ensure consensus on all changes since the 1st LC
3) Capture the resolution of any comments made during 2.

In reviewing the close to 200 mail messages on the documents since the
1st LC was issued, I see only one a few points that are still missing,
and I'll cover these below.  On a side note, as an experiment we'll be
tracking these issue via the tools issues page:
http://tools.ietf.org/wg/ccamp/trac/report/1

PLEASE reply to this message if you think there are other
points/discussions that haven't been addressed in the current set of
documents. Once this thread is closed, the 2nd LC will be initiated.

The remaining items come from the tread with the final message
http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html
The message is from me in response to Daniele's summary of next steps,
and has the following unresolved actions:

1)  No explicit indication of TSG in the label [SIGNALING]

  In signaling document section 6: Clarify related text to unambiguous
  identify the relationship between label length and TSG. Possible
  target text to change:
   Note that the
   Length field in the label format MAY be used to indicate the TS
   type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps)
   since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In
   some cases when there is no Link Management Protocol (LMP) or
   routing to make the two end points of the link to know the TSG,
   the TSG information used by another end can be deduced from the
   label format. For example, for HO ODU2 link, the value of the
   length filed will be 4 or 8, which indicates the TS granularity is
   2.5Gbps or 1.25Gbps, respectively.

2) Verify that the complete list of G-PIDs are defined [SIGNALING]

  In signaling document section 4, verify that all payload types
  defined in G.709 (Summarized in Table 15-8) can be represented.
  This issue can be resolved via an update or message to the list
  stating that the verification took place.

3) Identification of hexadecimal representation in G.709 vs
   decimal in GMPLS [INFO-MODEL]

  The authors had previously stated the intent to just make this clear
  in the signaling document.  I'd like to make an alternate proposal:
  let's do the the obvious and have the documents simply use the normal
  (IETF) convention of using a '0x' prefix anytime a hexadecimal value
  is represented. I believe this means that only the info-model draft
  needs to be updated.

I believe that's the complete list. Again:
PLEASE reply to this message if you think there are other
points/discussions that haven't been addressed in the current set of
documents.

Much thanks,
Lou

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 9 May 2013 07:12:18 +0000

Hi Lou,

For point 1), do you mean that you would like to have "TSG" field (ie., explicit indication) in the label format? Or just change the target text that you quoted? 
If what you meant is the latter, could you provide some proposed text to refine it.

For point 2), the GPIDs have been grouped based on Table 15-8 in G.709 (so it seems that some payload types in Table 15-8 are missed), but I think you more like the 1:1 mapping between the GPID defined in [SIGNALING] and Table 15-8. We will check and list all the ungrouped GPIDs. 

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, May 09, 2013 12:53 AM
To: CCAMP; [email-masked]; [email-masked]
Subject: Closing G.709 open issues

Authors/WG,

Much thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 09 May 2013 09:56:39 -0400

Just to be clear to all: My mail summarized the results of discussions
that occurred on the list whose results I believe are not reflected in
the current document set.  I identified 3 items, and hope I didn't miss
anything from the ~200 related messages on the list. I'm not trying to
change any conclusions, just ensure that they are documented.

Fatai,

See below for specific responses.

On 5/9/2013 3:12 AM, Fatai Zhang wrote:
> Hi Lou,
> 
> For point 1), do you mean that you would like to have "TSG" field
> (ie., explicit indication) in the label format? Or just change the
> target text that you quoted?
> 

This point was resolved in
http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html
to quote:
  On 3/21/2013 9:51 AM, Lou Berger wrote:
  > Daniele,
  ...
  > On 3/21/2013 9:34 AM, Daniele Ceccarelli wrote:
  >> Lou,
  >>
  >> OK. No changes to signaling re explicit indication of mapping
  >> and/or TSG in the label.
  >
  > I think it would be a good idea to add a comment on this in the
  > signaling document so that we don't have to revisit it yet again...
  >

> If what you meant is the latter, could you provide some proposed text to refine it.

I suggest that the authors propose some text on the list for the WG to
review.  Given that the explicit indication issue was raised by one of
the co-authors I suspect he can provide text that ensures the issue is
covered.  There's also some related text already on page 7 of the
framework draft.  If the authors are unable to come up with a proposal,
let me know and I'll propose something to the list.

> For point 2), the GPIDs have been grouped based on Table 15-8 in
> G.709 (so it seems that some payload types in Table 15-8 are missed),
> but I think you more like the 1:1 mapping between the GPID defined in
> [SIGNALING] and Table 15-8. 

The only thing I'm asking for is to verify that it is possible to
unambiguously signal the G.709 defined payload types with GMPLS. The
authors are free to use any approach, e.g., 1:1 or n:1+other signaled
information.

> We will check and list all the ungrouped GPIDs.
> 

If you think it's possible to indicate all G.709 defined payload types
using the current "grouped" approach, that works for me.  You just need
to state such on the list.

Perhaps it makes sense to just list how each PT in G.709 table 15-8 is
represented as a good sanity check. Such a list might also be useful
information to add to the draft.  Here's a start at such a list.  I've
flagged the results of a spot check (i.e., I probably have missed
something) of PTs for which I don't see an obvious mapping.

    G.709
   Payload
    Type       G-PID
   -------     -----
    0x01        ???
    0x02
    0x03
    0x04
    0x05
    0x06
    0x07
    0x08
    0x09
    0x0A
    0x0B
    0x0C
    0x0D
    0x0E
    0x0F
    0x10
    0x11
    0x12        ???
    0x13        ???
    0x14        ???
    0x15        ???
    0x16        ???
    0x17        ???
    0x18        ???
    0x19        ???
    0x1A
    0x1B        ???
    0x1C
    0x20
    0x21
    0x55        Unused
    0x66        Unused
    0x80-0x8F   ???
    0xFD        ?? (Is this needed?)
    0xFE        ?? (Is this needed?)
    0xFF        Unused

Thanks,
Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 9 May 2013 16:57:30 +0000

Hi Lou,

Wrt point 1) (TSG) we have 2 options.

1. leave the TSG being inferred by the label length and propose new text (see below).
2. add the TSG to the label.

Either solutions work for me, i just want to share some thoughts raised during discussions with Sergio and Fred.
A. From an implementation point of view, in case of multi-stage muxing multiple label lookups are needed to infer the TSG
B. Future proofness: we all know that TSG=10Gbps will be defined shorthly. This might make the TSG infer from label length not feasible.

Again, for me both solutions 1. and 2. work, A. And B. might not be major issues.

In case we go for 1. my proposed text is (feel free to amend):

"Please note that the TSG of the HO ODUk can be inferred from the length of the label.
In those cases where there is no LMP imposing the TSG to be used between two ends of a link,
Such information can be inferred from the signaling. E.g. In a HO ODU link a label lenght value
Of 4 would indicate TSG equal to 2,5Gbps while a value of 8 would correspond to a 1.25Gbps TSG".

BR
Daniele

>Sent: giovedì 9 maggio 2013 15.57
>To: Fatai Zhang
>Cc: CCAMP; 
>[email-masked]; 
>[email-masked]
>Subject: Re: Closing G.709 open issues
>
>
>Just to be clear to all: My mail summarized the results of 
>discussions that occurred on the list whose results I believe 
>are not reflected in the current document set.  I identified 3 
>items, and hope I didn't miss anything from the ~200 related 
>messages on the list. I'm not trying to change any 
>conclusions, just ensure that they are documented.
>
>Fatai,
>
>I suggest that the authors propose some text on the list for 
>the WG to review.  Given that the explicit indication issue 
>was raised by one of the co-authors I suspect he can provide 
>text that ensures the issue is covered.  There's also some 
>related text already on page 7 of the framework draft.  If the 
>authors are unable to come up with a proposal, let me know and 
>I'll propose something to the list.
>
>The only thing I'm asking for is to verify that it is possible 
>to unambiguously signal the G.709 defined payload types with 
>GMPLS. The authors are free to use any approach, e.g., 1:1 or 
>n:1+other signaled information.
>
>If you think it's possible to indicate all G.709 defined 
>payload types using the current "grouped" approach, that works 
>for me.  You just need to state such on the list.
>
>Perhaps it makes sense to just list how each PT in G.709 table 
>15-8 is represented as a good sanity check. Such a list might 
>also be useful information to add to the draft.  Here's a 
>start at such a list.  I've flagged the results of a spot 
>check (i.e., I probably have missed
>> To: CCAMP; [email-masked]; 
>> [email-masked]
>> 	I think all would like to wrap up the 709 documents 
>before Berlin.  
>> To do this we need to:

---

From: Lou Berger <[email-masked]>
Date: Thu, 09 May 2013 13:21:03 -0400

Daniele,
	Please see below:

> B. Future proofness: we all know that TSG=10Gbps will be defined shorthly. This might make the TSG infer from label length not feasible.

Sigh, I keep thinking we're "almost done" on 709 and another discussion
pops up...

So this is at least the third time we're discussing options 1 and 2.  In
the prior times, we've always agreed to follow 1.  So I'll quote myself,
from the last time around:
   Revising past decisions is fine if there's good cause, such as new
   information or issues identified/discovered...

So let me ask, is there good cause to revisit this decision?

> Of 4 would indicate TSG equal to 2,5Gbps while a value of 8 would correspond to a 1.25Gbps TSG".

Continuing in the case of 1, but how about:

  Please note that the TS granularity of a HO ODUk can be inferred from
  the length of the label. The values of 1, 4 and 16 indicate a TS
  granularity of 2.5Gps, while the values 2, 7, 32 and 80 indicate a TS
  granularity of 1.25Gps.

Note that I added the length value of 1 based on the table on page 7 of
the framework draft, but 1 isn't listed as a valid length value.  One of
these is wrong. (I didn't spend the time to figure out if the 1 needs to
be added to valid list or should be dropped from the suggested text.
Figured one of the authors would know this.)

Thanks,
Lou

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 10 May 2013 01:41:51 +0000

Hi Lou,

For point 1), "1" should be dropped and "7" should be corrected to "8" in your proposed text. 

I hesitate to make a decision on either approach, I would like to defer to the WG consensus.

For point 2), I compared [G.709-2003] and [G.709-2012], and checked the GPIDs defined in [RFC4328], I think the following new GPIDs (values could be 59-79) should be added (besides updating some GPIDs defined in RFC4328, like 32,47,49-52):

    Value       G-PID Type             LSP Encoding Type
     -----       ----------             -----------------
   59(TBA)     G.709 ODU-1.25G        G.709 ODUk 
   60(TBA)     G.709 ODU-any          G.709 ODUk
   61(TBA)     PCS                    G.709 ODUk (k=0)
   62(TBA)     FC-1200                G.709 ODUk (k=2e)
   63(TBA)     eOPU2                 G.709 ODUk (k=2)
   64(TBA)     STM-1                  G.709 ODUk (k=0)
   65(TBA)     STM-4                  G.709 ODUk (k=0)
   66(TBA)     FC-100                 G.709 ODUk (k=0)
   67(TBA)     FC-200                 G.709 ODUk (k=1)
   68(TBA)     FC-400                 G.709 ODUflex
   69(TBA)     FC-800                 G.709 ODUflex
   70(TBA)     IB SDR                 G.709 ODUflex
   71(TBA)     IB DDR                 G.709 ODUflex
   72(TBA)     IB QDR                 G.709 ODUflex
   73(TBA)     SDIa                   G.709 ODUk (k=0)
   74(TBA)     SDIb                   G.709 ODUk (k=1)
   75(TBA)     SDIc                   G.709 ODUk (k=1)
   76(TBA)     SDId                   G.709 ODUflex
   77(TBA)     SDIe                   G.709 ODUflex
   78(TBA)     SB/ESCON              G.709 ODUk (k=0)
   79(TBA)     DVB_ASI                G.709 ODUk (k=0)

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, May 10, 2013 1:21 AM
To: Daniele Ceccarelli
Cc: Fatai Zhang; CCAMP; [email-masked]; [email-masked]
Subject: Re: Closing G.709 open issues

Daniele,
	Please see below:

Thanks,
Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 10 May 2013 06:57:59 +0000

Lou,

I want to close the OTN work more than anyone else :-)
I just expressed loud thinking due to last evolution in OTN data plane, but i said, no major issue and i'm fine with 1. Let's go with 1.

I'm fine with the text you're proposing.

Thanks
Daniele

>Sent: giovedì 9 maggio 2013 19.21
>To: Daniele Ceccarelli
>Cc: Fatai Zhang; CCAMP; 
>> Either solutions work for me, i just want to share some 
>thoughts raised during discussions with Sergio and Fred.
>> A. From an implementation point of view, in case of 
>multi-stage muxing 
>> multiple label lookups are needed to infer the TSG B. Future 
>proofness: we all know that TSG=10Gbps will be defined 
>shorthly. This might make the TSG infer from label length not feasible.
>> 
>
>Sigh, I keep thinking we're "almost done" on 709 and another 
>discussion pops up...
>
>So this is at least the third time we're discussing options 1 
>and 2.  In the prior times, we've always agreed to follow 1.  
>So I'll quote myself, from the last time around:
>> In those cases where there is no LMP imposing the TSG to be used 
>> between two ends of a link, Such information can be inferred 
>from the 
>> signaling. E.g. In a HO ODU link a label lenght value Of 4 
>would indicate TSG equal to 2,5Gbps while a value of 8 would 
>correspond to a 1.25Gbps TSG".
>
>Note that I added the length value of 1 based on the table on 
>page 7 of the framework draft, but 1 isn't listed as a valid 
>length value.  One of these is wrong. (I didn't spend the time 
>to figure out if the 1 needs to be added to valid list or 
>should be dropped from the suggested text.

---

From: Lou Berger <[email-masked]>
Date: Fri, 10 May 2013 08:50:48 -0400

> For point 1), "1" should be dropped and "7" should be corrected to "8" in your proposed text. 

Great.

> I hesitate to make a decision on either approach, I would like to defer to the WG consensus.

I believe we already have a consensus position.  The question in my mail
was do we need to revisit it.  I take your response as a no. (thank you!)

> For point 2), I compared [G.709-2003] and [G.709-2012], and checked
> the GPIDs defined in [RFC4328], I think the following new GPIDs
> (values could be 59-79) should be added (besides updating some GPIDs
> defined in RFC4328, like 32,47,49-52):
> 

I suggest going through the full PT list and identifying them in the
table (as I started in my last message) so that there is no confusion in
implementations.

In the list below it looks like you have moved away from the 'grouped
G-PID' approach.  Is there a reason for this change?

Refer to
http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml
in subsequent comments.

>     Value       G-PID Type             LSP Encoding Type

Do you really need 3 G-PID types for an ODU (I thought TSG was already
covered)?

>    62(TBA)     FC-1200                G.709 ODUk (k=2e)
Why not us existing G-PID 58?

>    65(TBA)     STM-4                  G.709 ODUk (k=0)
Why not us existing G-PID 34?

>    69(TBA)     FC-800                 G.709 ODUflex
Why not us existing G-PID 58?

>    72(TBA)     IB QDR                 G.709 ODUflex
Can these be one value with rate implying SDR/DDR/QDR?

>    77(TBA)     SDIe                   G.709 ODUflex

Can these be one value with rate implying a-e?

>    78(TBA)     SB/ESCON              G.709 ODUk (k=0)
Why not us existing G-PID 56?

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 10 May 2013 08:53:32 -0400

Daniele,

Most excellent!

Once the three open items are addressed (by 2 updated drafts) we'll be
ready for the second LC.

Lou

---

From: John E Drake <[email-masked]>
Date: Fri, 10 May 2013 16:39:19 +0000

Can we please just go with 1?

Irrespectively Yours,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Daniele Ceccarelli
> Sent: Thursday, May 09, 2013 11:58 PM
> To: Lou Berger
> Cc: [email-masked]; CCAMP;
> Subject: Re: [CCAMP] Closing G.709 open issues
> 
>  Lou,
> 
> I want to close the OTN work more than anyone else :-) I just expressed
> loud thinking due to last evolution in OTN data plane, but i said, no
> major issue and i'm fine with 1. Let's go with 1.
> 
> >proofness: we all know that TSG=10Gbps will be defined shorthly. This
> >might make the TSG infer from label length not feasible.
> >>
> >
> discussion
> >So this is at least the third time we're discussing options 1 and 2.
> >In the prior times, we've always agreed to follow 1.
> >the framework draft, but 1 isn't listed as a valid length value.  One
> >of these is wrong. (I didn't spend the time to figure out if the 1
> >needs to be added to valid list or should be dropped from the
> suggested
> >text.
> >>> discussions that occurred on the list whose results I believe are
> >>> not reflected in the current document set.  I identified 3 items,
> >>> and hope I didn't miss anything from the ~200 related messages on
> >>> the list. I'm not trying to change any conclusions, just ensure
> that
> >>> they are documented.
> >>>
> >>> Fatai,
> >>>
> >>> I suggest that the authors propose some text on the list for the WG
> >>> to review.  Given that the explicit indication issue was raised by
> >>> one of the co-authors I suspect he can provide text that ensures
> the
> >>> issue is covered.  There's also some related text already on page 7
> >>> of the framework draft.  If the authors are unable to come up with
> a
> >>> proposal, let me know and I'll propose something to the list.
> >>>
> >>> authors are free to use any approach, e.g., 1:1 or n:1+other
> >>> signaled information.
> >>>
> >>> If you think it's possible to indicate all G.709 defined payload
> >>> types using the current "grouped" approach, that works for me.  You
> >>> just need to state such on the list.
> >>>
> >>> 15-8 is represented as a good sanity check. Such a list might also
> >>> be useful information to add to the draft.  Here's a start at such
> a
> >>> list.  I've flagged the results of a spot check (i.e., I probably
> >>> have missed
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 13 May 2013 03:33:04 +0000

Hi Lou,

I think you have two major points here. 

(1) Do you really need 3 G-PID types for an ODU (I thought TSG was already covered)?

I think this has been discussed for quite long time before Vancouver meeting, which was famous as "penultimate" issue. Note that this TSG in GPID is different from the *implicit* TSG in label format.

I don't think we need discuss this anymore.

(2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs defined in this draft)

We realize that it is safe to use 1:1 mapping approach to avoid some potential issues after investigation. We know this payload types have been defined by G.709 (data plane), so physically it is better to use 1:1 mapping approach. 
For the potential issues I mentioned above, for example, we cannot use the existing 34 to represent 'STM-1' and 'STM-4 ', because it is impossible to differentiate which one is 'STM-1' or 'STM-4'. In addition, from the concept of payload type, we know that e.g, FC-100 is different from FC-800, right? So, it is better to assign different GPIDs to these different payload types defined by the data plane.

Furthermore, I think it is much cheaper to create new GPIDs in the control plane than in the data plane (these payload types will be carried in the OH). 

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, May 10, 2013 8:51 PM
To: Fatai Zhang
Cc: Daniele Ceccarelli; CCAMP; [email-masked]; [email-masked]
Subject: Re: Closing G.709 open issues

Great.

Refer to

Thanks,
Lou

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Mon, 13 May 2013 07:45:27 +0000

Hi Fatai,

I agree with you, for both point 1 and 2.

Best Regards
Sergio

Belotti Sergio-  System Architect
ALCATE-LUCENT  Optics Division
via Trento 30 Vimercate (MB) - Italy
phone +39 (039) 6863033
-----Messaggio originale-----
Da: Fatai Zhang [mailto:[email-masked]] 
Inviato: lunedì 13 maggio 2013 5.33
A: Lou Berger
Cc: Daniele Ceccarelli; CCAMP; [email-masked]; [email-masked]
Oggetto: RE: Closing G.709 open issues

Hi Lou,

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, May 10, 2013 8:51 PM
To: Fatai Zhang
Cc: Daniele Ceccarelli; CCAMP; [email-masked]; [email-masked]
Subject: Re: Closing G.709 open issues

Great.

Refer to

Thanks,
Lou

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 14 May 2013 05:53:03 +0000

Hi all,

Thanks, Sergio.

I would like to double check if everything is OK before we update the signaling draft.

I would assume the WG is happy with 1:1 mapping approach and the new GPIDs listed below if there is no more comment until this Wed. 

Best Regards

Fatai

-----Original Message-----
From: BELOTTI, SERGIO (SERGIO) [mailto:[email-masked]] 
Sent: Monday, May 13, 2013 3:45 PM
To: Fatai Zhang; Lou Berger
Cc: Daniele Ceccarelli; CCAMP; [email-masked]; [email-masked]
Subject: R: Closing G.709 open issues

Hi Fatai,

Best Regards
Sergio

-----Messaggio originale-----
Da: Fatai Zhang [mailto:[email-masked]] 
Inviato: lunedì 13 maggio 2013 5.33
A: Lou Berger
Cc: Daniele Ceccarelli; CCAMP; [email-masked]; [email-masked]
Oggetto: RE: Closing G.709 open issues

Hi Lou,

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, May 10, 2013 8:51 PM
To: Fatai Zhang
Cc: Daniele Ceccarelli; CCAMP; [email-masked]; [email-masked]
Subject: Re: Closing G.709 open issues

Great.

Refer to

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 14 May 2013 10:00:34 -0400

Fatai, Sergio,
	I haven't had time to go find the old mail covering the topic you
mentioned (which is why I didn't respond yesterday):
> I think this has been discussed for quite long time before Vancouver
> meeting, which was famous as "penultimate" issue.
>

My memory is that the consensus at the time was that G.709 would
continue to use the current generic approach to edge adaptation &
G-PIDs, and that (some of) the G.709 authors would submit a draft that
would address adaptation in a generic fashion.

Do you think this characterization is mistaken?  (If so, time to go
searching for the old discussion, if not we can move on.)

Assuming no, then it seems to me that you are going against this
discussion & consensus by now introducing a 1:1/bandwidth specific
mapping approach. Do you disagree?  If not, do you think there's
justification to reopen this discussion?

Independent of the mapping approach and in order to ensure this issue is
closed and does not again resurface, I also request (again) that the
editors of the draft provide (and include in the document) a full list
of Payload Type values (with the 0x value prefix or the values in
decimal) and their corresponding G-PID values.  Also including Encoding
Type as you have below is a good addition -- great idea!

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 15 May 2013 08:20:25 +0000

Hi Lou,

Just a bit. 

>My memory is that the consensus at the time was that G.709 
>would continue to use the current generic approach to edge 
>adaptation & G-PIDs, and that (some of) the G.709 authors 
>would submit a draft that would address adaptation in a 
>generic fashion.
>

If i correctly remember we agreed to solve the routing issu in a generic approach, not the signaling one.
It is possible to assume that the adaptation is a known info to the operator and hence that the advertisement can be postponed and addressed in a generic way but it needs to be signaled.

This is an hortogonal issue with respect to the mapping of G-PID, which has always been assumed to be 1:1 with G.709 values.
The 1:1 *mapping* approach used by Fatai is different from the *mapping" protocol like GFP, AMP that we discussed before.

BR
Daniele, Sergio, Fatai

>Sent: martedì 14 maggio 2013 16.01
>To: Fatai Zhang
>Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; 
>	I haven't had time to go find the old mail covering the 
>topic you mentioned (which is why I didn't respond yesterday):
>My memory is that the consensus at the time was that G.709 
>would continue to use the current generic approach to edge 
>adaptation & G-PIDs, and that (some of) the G.709 authors 
>would submit a draft that would address adaptation in a 
>generic fashion.
>
>Do you think this characterization is mistaken?  (If so, time 
>to go searching for the old discussion, if not we can move on.)
>
>Assuming no, then it seems to me that you are going against 
>this discussion & consensus by now introducing a 1:1/bandwidth 
>specific mapping approach. Do you disagree?  If not, do you 
>think there's justification to reopen this discussion?
>
>Independent of the mapping approach and in order to ensure 
>this issue is closed and does not again resurface, I also 
>request (again) that the editors of the draft provide (and 
>include in the document) a full list of Payload Type values 
>(with the 0x value prefix or the values in
>decimal) and their corresponding G-PID values.  Also including 
>Encoding Type as you have below is a good addition -- great idea!
>
>Lou
>
>> I would assume the WG is happy with 1:1 mapping approach and 
>the new GPIDs listed below if there is no more comment until this Wed. 
>> 
>> 
>> 
>> 
>> Best Regards
>> 
>> Fatai
>> 
>> 
>> From: BELOTTI, SERGIO (SERGIO) 
>> [mailto:[email-masked]]
>> Cc: Daniele Ceccarelli; CCAMP; 
>> Cc: Daniele Ceccarelli; CCAMP; 
>> I think this has been discussed for quite long time before 
>Vancouver meeting, which was famous as "penultimate" issue. 
>Note that this TSG in GPID is different from the *implicit* 
>TSG in label format.
>> 
>> We realize that it is safe to use 1:1 mapping approach to 
>avoid some potential issues after investigation. We know this 
>payload types have been defined by G.709 (data plane), so 
>physically it is better to use 1:1 mapping approach. 
>> For the potential issues I mentioned above, for example, we 
>cannot use the existing 34 to represent 'STM-1' and 'STM-4 ', 
>because it is impossible to differentiate which one is 'STM-1' 
>or 'STM-4'. In addition, from the concept of payload type, we 
>know that e.g, FC-100 is different from FC-800, right? So, it 
>is better to assign different GPIDs to these different payload 
>types defined by the data plane.
>> 
>> Furthermore, I think it is much cheaper to create new GPIDs 
>in the control plane than in the data plane (these payload 
>types will be carried in the OH). 
>> 
>> 
>> 
>> 
>> Best Regards
>> 
>> Fatai
>> 
>> 
>> Cc: Daniele Ceccarelli; CCAMP; 
>> I believe we already have a consensus position.  The question in my 
>> mail was do we need to revisit it.  I take your response as a no. 
>> (thank you!)
>> 
>> table (as I started in my last message) so that there is no 
>confusion 
>> in implementations.
>>

---

From: Lou Berger <[email-masked]>
Date: Wed, 15 May 2013 07:22:23 -0400

Daniele,

On May 15, 2013 4:20:25 AM Daniele Ceccarelli 
<[email-masked]> wrote:
> Hi Lou,
>
> Just a bit.
> >My memory is that the consensus at the time was that G.709 would continue 
> to use the current generic approach to edge adaptation & G-PIDs, and that 
> (some of) the G.709 authors would submit a draft that would address 
> adaptation in a generic fashion.
> >
>

We must be thinking of different threads. The one I'm thinking of started 
with the comment along the lines of "why only some G-PIDs represented in 
the ADAPTATION object" and concluded with the agreement to drop the object 
and follow the current generic approach as well as look into a non-OTN 
specific solution in a new draft.  At least that's how I remember it....

> It is possible to assume that the adaptation is a known info to the 
> operator and hence that the advertisement can be postponed and addressed in 
> a generic way but it needs to be signaled.
>
> This is an hortogonal issue with respect to the mapping of G-PID, which has 
> always been assumed to be 1:1 with G.709 values.

humm, this seems inconsistent with Fatai  recently suggesting that i was 
asking for a "non-grouped" approach.  At the time, I was really just 
thinking about the values missing in the list I sent out. I don't recall 
any other discussion on moving away from the past 709 G-PID assignment 
approach.

> The 1:1 *mapping* approach used by Fatai is different from the *mapping" 
> protocol like GFP, AMP that we discussed before.
>

It looks like we both/all should take a look at the archives to refresh our 
memories....

Thanks,
 Lou

> >From: Lou Berger [mailto:[email-masked]] Sent: martedì 14 maggio 2013 16.01
> >To: Fatai Zhang
> >My memory is that the consensus at the time was that G.709 would continue 
> to use the current generic approach to edge adaptation & G-PIDs, and that 
> (some of) the G.709 authors would submit a draft that would address 
> adaptation in a generic fashion.
> >
> discussion & consensus by now introducing a 1:1/bandwidth specific mapping 
> approach. Do you disagree?  If not, do you think there's justification to 
> reopen this discussion?
> >
> editors of the draft provide (and include in the document) a full list of 
> Payload Type values (with the 0x value prefix or the values in
> >> I would like to double check if everything is OK before we >update the 
> signaling draft.
> >> I would assume the WG is happy with 1:1 mapping approach and >the new 
> GPIDs listed below if there is no more comment until this Wed.
> >>
> >> Best Regards
> >> Fatai
> >>
> >> (1) Do you really need 3 G-PID types for an ODU (I thought >TSG was 
> already covered)?
> >> I think this has been discussed for quite long time before >Vancouver 
> meeting, which was famous as "penultimate" issue. >Note that this TSG in 
> GPID is different from the *implicit* >TSG in label format.
> >> We realize that it is safe to use 1:1 mapping approach to >avoid some 
> potential issues after investigation. We know this >payload types have been 
> defined by G.709 (data plane), so >physically it is better to use 1:1 
> mapping approach. For the potential issues I mentioned above, for example, 
> we >cannot use the existing 34 to represent 'STM-1' and 'STM-4 ', >because 
> it is impossible to differentiate which one is 'STM-1' >or 'STM-4'. In 
> addition, from the concept of payload type, we >know that e.g, FC-100 is 
> different from FC-800, right? So, it >is better to assign different GPIDs 
> to these different payload >types defined by the data plane.
> >> Furthermore, I think it is much cheaper to create new GPIDs >in the 
> control plane than in the data plane (these payload >types will be carried 
> in the OH).
> >>
> >> Best Regards
> >> Fatai
> >>
> >>> For point 1), "1" should be dropped and "7" should be >corrected to "8" 
> in your proposed text. >> >> Great.
> >> >>>
> >>> I hesitate to make a decision on either approach, I would >like to 
> defer to the WG consensus.
> >>>
> >>> the GPIDs defined in [RFC4328], I think the following new GPIDs >>> 
> (values could be 59-79) should be added (besides updating >some GPIDs >>> 
> table (as I started in my last message) so that there is no >confusion in 
> implementations.
> >> In the list below it looks like you have moved away from the >'grouped 
> >>>    59(TBA)     G.709 ODU-1.25G        G.709 ODUk 60(TBA)     G.709 
> ODU-any          G.709 ODUk
> >> Do you really need 3 G-PID types for an ODU (I thought TSG >was already 
> covered)?

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 15 May 2013 11:54:57 +0000

We (as authors" were asked to cope with the remaining issues to start second LC.
One these "remaining issues" was as fro Lou's mil of May 9th

This is concluded by Fatai answer regarding G-PID check and 1:1 mapping.

FATAI> For point 2), I compared [G.709-2003] and [G.709-2012], and checked the GPIDs defined in [RFC4328], I think the following new GPIDs (values could be 59-79) should be added (besides updating some GPIDs defined in RFC4328, like 32,47,49-52):

All this has nothing to do with specifc ADAPTATION object , for which  I was always in favour but it seems as though it is linked to MRN discussion and out of specifc OTN. 

Hope this can help.

Best Regards
Sergio

-----Messaggio originale-----
Da: Lou Berger [mailto:[email-masked]] 
Inviato: mercoledì 15 maggio 2013 13.22
A: Daniele Ceccarelli; Fatai Zhang
Cc: BELOTTI, SERGIO (SERGIO); CCAMP; [email-masked]; [email-masked]
Oggetto: RE: Closing G.709 open issues

Daniele,

Thanks,
 Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 15 May 2013 10:57:46 -0400

Sergio/Fatai,

> This is concluded by Fatai answer regarding G-PID check and 1:1 mapping.

And, based on the discussion, I (to be clear, as WG chair) have revised
the request by asking:
  "that the editors of the draft provide (and include in the document)
   a full list of Payload Type values (with the 0x value prefix or the
   values in decimal) and their corresponding G-PID values.  Also
   including Encoding Type as you [Fatai] have below is a good addition
   -- great idea!"

Given the level of discussion of this thread, I think this is a
completely reasonable way to avoid future confusion, particularly in
implementations.

Do the Authors/Editor need help in generating this complete list?

Do the Authors/Editor want (me) to issue a call for input on this list?
 I suspect some in WG will be happy to jump in as it's an easy way to
get added as a contributor to the signaling draft.

> All this has nothing to do with specifc ADAPTATION object , for which  I was always in favour but it seems as though it is linked to MRN discussion and out of specifc OTN. 

So I went looking for past discussions on this, and this is what I find:

- From http://www.ietf.org/mail-archive/web/ccamp/current/msg13598.html
On 7/19/2012 11:45 AM, Lou Berger wrote:
> (As participant in thread) I read that the conclusion is to not optimize
> for a very special corner case and:
> 1) basically treat the intra-OTN case the same as any other MRN/MLN case
>    (leveraging GPID, and no new hierarchy object)
> 2) Use Daniele's new draft on MRN/MLN as the starting point in the
> discussion of how to address the limitations in MRN/MLN identified in
> this discussion.

>From http://tools.ietf.org/agenda/84/slides/slides-84-ccamp-7.pdf
> G-PID Value Extension
> o Extended G-PID for G.709 ODU client signals:
>   Value G-PID Type TSG (LO ODU into requested LSP)
>   ----- ---------- ----------------
>   47 G.709 ODU 2.5Gbps [RFC4328]
>   59(TBA) G.709 ODU-1.25G 1.25Gbps (new)
>   60(TBA) G.709 ODU-any either 1.25 or 2.5Gbps(new)
> 
> o Added other new G-PID values for new client signals supported by G.709V3
>   Value G-PID Type
>   ----- ----------
>   61(TBA) CBRc (via GMP)
>   62(TBA) 1000BASE-X
>   63(TBA) FC-1200
> 
> o Updated some existing G-PID description to support new 1.25G, 100G, 
>   supra-2.488G client signals, such as 32 for ATM, 49 for asynchronous 
>   CBR , 50 for synchronous CBR , 51 for BSOT, 52 for BSNT.

I have not interest/need to revist past consensus on G-PIDs & TSGs, so
will limit my comments to the newly defined G-PIDs.

My questions on the new G-PIDs come down to:
- Why are rate specific G-PIDs being proposed (rather than
  continuing to use the previous approach documented in the draft
  and in Section 3.1.3 of rfc4328)?

- Why are new values being defined rather than using existing
  values, e.g., G-PID 56?

That's it.

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 17 May 2013 07:58:17 +0000

Hi Lou,

I thought it should be sufficient for me to identify the *updated* and *new* G-PIDs in this draft (I compared [G.709-2003] and [G.709-2012], and checked RFC4328), but I would be happy to provide a full list for your request.

Please see the list below, and the new payload types introduced by [G.709-2012] (and the corresponding new G-PIDs defined in this draft) are in the light blue cells.

Please check if there is anything missed or wrong. Note that GPIDs like 32,47,49-52 have been updated in this draft.

Note that we as authors welcome any contributors for their contribution.

For you convenience, I also attached the word document.

G-PIDs vs Payload types defined in Table 15-8 of G.709

G-PID

LSP Encoding

Payload Type in Hex code defined in G.709

Note

Interpretation from G.709

None

0x01

Not needed

Experimental mapping (Note 3)

49

G.709 ODUk, G.709 OCh

0x02

1)G-PID defined in RFC4328;

2) Updated in this draft.

Asynchronous CBR mapping, see clause 17.2

50

G.709 ODUk

0x03

ditto

Bit synchronous CBR mapping, see clause 17.2

32

SDH, G.709 ODUk

0x04

ditto

ATM mapping, see clause 17.3

54

G.709 ODUk (and SDH)

0x05

G-PIDs defined in RFC4328 with two kinds of GFPs (Ethernet MAC (framed GFP)

GFP mapping, see clause 17.4

None

0x06

Not needed and Not defined in RFC4328

Virtual Concatenated signal, see clause 18 (Note 5)

61(TBA)

G.709 ODUk (k=0,3,4)

0x07

Is being defined in this draft (new payload type defined in [G.709-2012])

PCS codeword transparent Ethernet mapping:

·      1000BASE-X into OPU0, see clauses 17.7.1 and 17.7.1.1

·      40GBASE-R into OPU3, see clauses 17.7.4 and 17.7.4.1

·      100GBASE-R into OPU4, see clauses 17.7.5 and 17.7.5.1

62(TBA)

G.709 ODUk (k=2e)

0x08

ditto

FC-1200 into OPU2e mapping, see clause 17.8.2

63(TBA)

G.709 ODUk (k=2)

0x09

ditto

GFP mapping into Extended OPU2 payload, see clause 17.4.1 (Note 6)

64(TBA)

G.709 ODUk (k=0)

0x0A

ditto

STM-1 mapping into OPU0, see clause 17.7.1

65(TBA)

G.709 ODUk (k=0)

0x0B

ditto

STM-4 mapping into OPU0, see clause 17.7.1

66(TBA)

G.709 ODUk (k=0)

0x0C

ditto

FC-100 mapping into OPU0, see clause 17.7.1

67(TBA)

G.709 ODUk (k=1)

0x0D

ditto

FC-200 mapping into OPU1, see clause 17.7.2

68(TBA)

G.709 ODUflex

0x0E

ditto

FC-400 mapping into OPUflex, see clause 17.9

69(TBA)

G.709 ODUflex

0x0F

ditto

FC-800 mapping into OPUflex, see clause 17.9

51

G.709 ODUk

0x10

1)G-PID defined in RFC4328;

2) Updated in this draft.

Bit stream with octet timing mapping, see clause 17.6.1

52

G.709 ODUk

0x11

ditto

Bit stream without octet timing mapping, see clause 17.6.2

70(TBA)

G.709 ODUflex

0x12

Is being defined in this draft (new payload type defined in [G.709-2012])

IB SDR  mapping into OPUflex, see 17.9

71(TBA)

G.709 ODUflex

0x13

ditto

IB DDR mapping into OPUflex, see 17.9

72(TBA)

G.709 ODUflex

0x14

ditto

IB QDR mapping into OPUflex, see 17.9

73(TBA)

G.709 ODUk (k=0)

0x15

ditto

SDI  mapping into OPU0, see 17.7.1

74(TBA)

G.709 ODUk (k=1)

0x16

ditto

(1.485/1.001) Gbit/s SDI mapping into OPU1, see 17.7.2

75(TBA)

G.709 ODUk (k=1)

0x17

ditto

1.485 Gbit/s SDI mapping into OPU1, see 17.7.2

76(TBA)

G.709 ODUflex

0x18

ditto

(2.970/1.001) Gbit/s SDI mapping into OPUflex, see 17.9

77(TBA)

G.709 ODUflex

0x19

ditto

2.970 Gbit/s SDI mapping into OPUflex, see 17.9

78(TBA)

G.709 ODUk (k=0)

0x1A

ditto

SBCON/ESCON mapping into OPU0, see 17.7.1

79(TBA)

G.709 ODUk (k=0)

0x1B

ditto

DVB_ASI mapping into OPU0, see 17.7.1

47

G.709 ODUk

0x20

1) G-PIDs defined in RFC4328.

2) Updated in this draft.

ODU multiplex structure supporting ODTUjk only, see clause 19 (AMP only)

59/60

G.709 ODUk

0x21

1)Are being defined in this draft (new payload type defined in [G.709-2012]);

2) 59 for G.709 ODU-1.25G; 60 for G.709 ODU-any

ODU multiplex structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see clause 19 (GMP capable) (Note 7)

None

55

Not needed

Not available (Note 2)

None

66

Not needed

Not available (Note 2)

None

80-8F

Not needed

Reserved codes for proprietary use (Note 4)

None

FD

Not needed

NULL test signal mapping, see clause 17.5.1

None

FE

Not needed

PRBS test signal mapping, see clause 17.5.2

None

FF

Not needed

Not available (Note 2)

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Wednesday, May 15, 2013 10:58 PM
To: BELOTTI, SERGIO (SERGIO); Fatai Zhang
Cc: Daniele Ceccarelli; CCAMP; [email-masked]
Subject: Re: R: Closing G.709 open issues

Sergio/Fatai,

the request by asking:

   -- great idea!"

implementations.

  values, e.g., G-PID 56?

That's it.

Lou

>> If i correctly remember we agreed to solve the routing issu in a generic

>> approach, not the signaling one.

>>>> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs

>> defined in this draft)

>>>>> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-paramet

>>>> ers.xml

---

From: Lou Berger <[email-masked]>
Date: Fri, 17 May 2013 11:16:04 -0400

Fatai,
	
That's a great start for the WG.  Thank you.

To answer your implied question as to why my request for the full list.
 My feeling is that there have been too many "surprises" on the 709
documents in areas that I thought were either obvious (but from the IETF
& GMPLS context, not ITU-T or G.709 perspectives) or resolved by past
discussions.  At this point, as co-chair and Document shepherd, I want
to ensure that any open point on the documents are unambiguously closed
and that past discussions (i.e., points of consensus) are 100% captured,
so that we can smoothly move through the planned second LC and
publication request.

To that end, in my previous message I asked two questions about points
where it seems you are proposing moving away from what has been
previously been discussed & agreed to by the WG.  Can you answer the

Much thanks,
Lou

On 5/17/2013 3:58 AM, Fatai Zhang wrote:> Hi Lou,
>
> I thought it should be sufficient for me to identify the **updated** and
> **new** G-PIDs in this draft (I compared [G.709-2003] and [G.709-2012],
> and checked RFC4328), but I would be happy to provide a full list for
> your request.
>
> Please see the list below, and the new payload types introduced by
> [G.709-2012] (and the corresponding new G-PIDs defined in this draft)
> are in the light blue cells.
>
> Please check if there is anything missed or wrong. Note that GPIDs like
> 32,47,49-52 have been updated in this draft.
>
> *G-PIDs vs **Payload types defined in Table 15-8 of G.709*
>
> G-PID
> 	
> LSP Encoding
> 	
> Payload Type in Hex codedefined in G.709
> 	
> Note
> 	
> Interpretationfrom G.709
> None
> 	
>
> 	
> 0x01
> 	
> Not needed
> 	
> [email-masked]
>> FATAI> For point 2), I compared [G.709-2003] and [G.709-2012], and
checked the GPIDs defined in [RFC4328], I think the following new GPIDs
(values could be 59-79) should be added (besides updating some GPIDs
defined in RFC4328, like 32,47,49-52):
>> All this has nothing to do with specifc ADAPTATION object , for which
 I was always in favour but it seems as though it is linked to MRN
discussion and out of specifc OTN.
>> Inviato: mercoledì15 maggio 2013 13.22
>> Cc: BELOTTI, SERGIO (SERGIO); CCAMP;
>>>> My memory is that the consensus at the time was that G.709 would
continue
>>>> From: Lou Berger [mailto:[email-masked]] Sent: martedì14 maggio
2013 16.01
>>>>          I haven't had time to go find the old mail covering the
topic you
>>>> My memory is that the consensus at the time was that G.709 would
continue
>>> discussion & consensus by now introducing a 1:1/bandwidth specific
mapping
>>>>> Inviato: lunedì13 maggio 2013 5.33
>>>>> A: Lou Berger
>>> we >cannot use the existing 34 to represent 'STM-1' and 'STM-4 ',
>because
>confusion in

---

From: Lou Berger <[email-masked]>
Date: Fri, 17 May 2013 12:17:02 -0400

Authors/WG,
	From the mail on the list it seems to me that we've reached closure on
Issue #48: "Document no explicit indication of TSG in the label"
(http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48).  I'd like to
confirm my reading.

As I read the list, this issue will be resolved by making the following
change to draft-ietf-ccamp-gmpls-signaling-g709v3.

OLD
  Note that the

NEW
  Please note that the TS granularity of an HO ODUk can be inferred from
  the length of the label. The values of 4 and 16 indicate a TS
  granularity of 2.5Gps, while the values 2, 8, 32 and 80 indicate a TS
  granularity of 1.25Gps.

Please speak up if you disagree with this resolution.

Thanks,
Lou

---

From: John E Drake <[email-masked]>
Date: Fri, 17 May 2013 17:15:23 +0000

Lou,

I think the original text is fine and your attempted re-write completely mangled its meaning.  The label is a bit vector whose length is equal to the ODUk rate / TSG. 

Irrespectively Yours,

John

> Of Lou Berger
> Sent: Friday, May 17, 2013 9:17 AM
> To: Fatai Zhang
> Cc: [email-masked]; CCAMP; draft-
> [email-masked]
> Subject: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709
> open issues)
> 
> Authors/WG,
> 	From the mail on the list it seems to me that we've reached
> closure on Issue #48: "Document no explicit indication of TSG in the
> label"

---

From: Lou Berger <[email-masked]>
Date: Fri, 17 May 2013 16:32:31 -0400

John,
	I guess you haven't been paying attention!  The rewrite originated from
Daniele, was tweaked by me and then fixed by Fatai.

Do you have an alternate proposal to address issue#48?
Issue #48="In signaling document section 6: Clarify related text [i.e.,
the OLD text] to unambiguously identify the relationship between label
length and TSG."

Thanks,
Lou

---

From: Khuzema Pithewan <[email-masked]>
Date: Sun, 19 May 2013 12:26:52 +0000

Hi Fatai,

I think we should (continue to)  keep GPid as technology indicator and use rate in signal Type to make sense of payload.

For example, FC-100, GPid = 43 (FiberChannel) and SignalType=ODU0 (10), will give you payload FC-100.

Do you see any case, where it can be ambiguous?

Thanks
Khuzema

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fatai Zhang
Sent: Friday, May 17, 2013 1:28 PM
To: Lou Berger; BELOTTI, SERGIO (SERGIO)
Cc: CCAMP; [email-masked]
Subject: Re: [CCAMP] R: Closing G.709 open issues

Hi Lou,

G-PID

LSP Encoding

Note

None

0x01

Not needed

49

G.709 ODUk, G.709 OCh

0x02

50

G.709 ODUk

0x03

ditto

32

SDH, G.709 ODUk

0x04

ditto

54

G.709 ODUk (and SDH)

0x05

None

0x06

61(TBA)

G.709 ODUk (k=0,3,4)

0x07

62(TBA)

G.709 ODUk (k=2e)

0x08

ditto

63(TBA)

G.709 ODUk (k=2)

0x09

ditto

64(TBA)

G.709 ODUk (k=0)

0x0A

ditto

65(TBA)

G.709 ODUk (k=0)

0x0B

ditto

66(TBA)

G.709 ODUk (k=0)

0x0C

ditto

67(TBA)

G.709 ODUk (k=1)

0x0D

ditto

68(TBA)

G.709 ODUflex

0x0E

ditto

69(TBA)

G.709 ODUflex

0x0F

ditto

51

G.709 ODUk

0x10

52

G.709 ODUk

0x11

ditto

70(TBA)

G.709 ODUflex

0x12

71(TBA)

G.709 ODUflex

0x13

ditto

72(TBA)

G.709 ODUflex

0x14

ditto

73(TBA)

G.709 ODUk (k=0)

0x15

ditto

74(TBA)

G.709 ODUk (k=1)

0x16

ditto

75(TBA)

G.709 ODUk (k=1)

0x17

ditto

76(TBA)

G.709 ODUflex

0x18

ditto

77(TBA)

G.709 ODUflex

0x19

ditto

78(TBA)

G.709 ODUk (k=0)

0x1A

ditto

79(TBA)

G.709 ODUk (k=0)

0x1B

ditto

47

G.709 ODUk

0x20

59/60

G.709 ODUk

0x21

None

55

Not needed

Not available (Note 2)

None

66

Not needed

Not available (Note 2)

None

80-8F

Not needed

None

FD

Not needed

None

FE

Not needed

None

FF

Not needed

Not available (Note 2)

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Wednesday, May 15, 2013 10:58 PM
To: BELOTTI, SERGIO (SERGIO); Fatai Zhang
Cc: Daniele Ceccarelli; CCAMP; [email-masked]
Subject: Re: R: Closing G.709 open issues

Sergio/Fatai,

the request by asking:

   -- great idea!"

implementations.

  values, e.g., G-PID 56?

That's it.

Lou

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

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 20 May 2013 09:09:01 +0000

Hi Lou,

I think my mail on March 13rd may have answered your following comments. My response quoted as follows.

In addition, if people look at the full list that I provided, I think people can realize that RFC4328 (section 3.1.3) used the same approach as the current approach of this draft (ie., 1:1 mapping between GPIDs and payload types defined by G.709), ie., we are following what RFC4328 did.

BTW, I am not sure if we need spend so much on discussing this point (because there is no issue to stick to the data plane by using the current approach of this draft).

======================================================================================================================

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Friday, May 17, 2013 11:16 PM
To: Fatai Zhang
Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; [email-masked]
Subject: Re: R: Closing G.709 open issues

Fatai,

publication request.

Much thanks,

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Mon, 20 May 2013 09:15:54 +0000

Hi Lou,

To be precise, I should use "the proposed approach" to replace "the current approach".

Best Regards

Fatai

From: Fatai Zhang
Sent: Monday, May 20, 2013 5:09 PM
To: 'Lou Berger'
Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; [email-masked]
Subject: RE: R: Closing G.709 open issues

Hi Lou,

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Friday, May 17, 2013 11:16 PM
To: Fatai Zhang
Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; [email-masked]
Subject: Re: R: Closing G.709 open issues

Fatai,

publication request.

Much thanks,

Lou

---

From: Khuzema Pithewan <[email-masked]>
Date: Mon, 20 May 2013 11:57:37 +0000

Hi,

After offline discussion, agreed that G.709' Payload code is required to have 1:1 mapping with GPid, to resolve STM-1 and STM-4 ambiguity and to achieve, in general coherency between spec of Data plane and Control plane for interpretation of payload Identifier.

However, there is another question that has popped up. Need WG opinion on this.

G.709-2012 Table 15-8 defines some reserved code point  to be used for proprietary payloads and also says that these payloads code will not be subject to standardization.

Question is, Should we also reserve equivalent number of GPIds in signaling that can be used along with those reserved dataplane code points? For reference, pls look at the bottom few lines in the table that Fatai sent out.

Best Regards
Khuzema

From: [email-masked] [mailto:[email-masked]] On Behalf Of Khuzema Pithewan
Sent: Sunday, May 19, 2013 5:57 PM
To: Fatai Zhang; Lou Berger; BELOTTI, SERGIO (SERGIO)
Cc: CCAMP; [email-masked]
Subject: Re: [CCAMP] R: Closing G.709 open issues

Hi Fatai,

Thanks
Khuzema

Hi Lou,

G-PID

LSP Encoding

Note

None

0x01

Not needed

49

G.709 ODUk, G.709 OCh

0x02

50

G.709 ODUk

0x03

ditto

32

SDH, G.709 ODUk

0x04

ditto

54

G.709 ODUk (and SDH)

0x05

None

0x06

61(TBA)

G.709 ODUk (k=0,3,4)

0x07

62(TBA)

G.709 ODUk (k=2e)

0x08

ditto

63(TBA)

G.709 ODUk (k=2)

0x09

ditto

64(TBA)

G.709 ODUk (k=0)

0x0A

ditto

65(TBA)

G.709 ODUk (k=0)

0x0B

ditto

66(TBA)

G.709 ODUk (k=0)

0x0C

ditto

67(TBA)

G.709 ODUk (k=1)

0x0D

ditto

68(TBA)

G.709 ODUflex

0x0E

ditto

69(TBA)

G.709 ODUflex

0x0F

ditto

51

G.709 ODUk

0x10

52

G.709 ODUk

0x11

ditto

70(TBA)

G.709 ODUflex

0x12

71(TBA)

G.709 ODUflex

0x13

ditto

72(TBA)

G.709 ODUflex

0x14

ditto

73(TBA)

G.709 ODUk (k=0)

0x15

ditto

74(TBA)

G.709 ODUk (k=1)

0x16

ditto

75(TBA)

G.709 ODUk (k=1)

0x17

ditto

76(TBA)

G.709 ODUflex

0x18

ditto

77(TBA)

G.709 ODUflex

0x19

ditto

78(TBA)

G.709 ODUk (k=0)

0x1A

ditto

79(TBA)

G.709 ODUk (k=0)

0x1B

ditto

47

G.709 ODUk

0x20

59/60

G.709 ODUk

0x21

None

55

Not needed

Not available (Note 2)

None

66

Not needed

Not available (Note 2)

None

80-8F

Not needed

None

FD

Not needed

None

FE

Not needed

None

FF

Not needed

Not available (Note 2)

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Wednesday, May 15, 2013 10:58 PM
To: BELOTTI, SERGIO (SERGIO); Fatai Zhang
Cc: Daniele Ceccarelli; CCAMP; [email-masked]
Subject: Re: R: Closing G.709 open issues

Sergio/Fatai,

the request by asking:

   -- great idea!"

implementations.

  values, e.g., G-PID 56?

That's it.

Lou

---

From: John E Drake <[email-masked]>
Date: Mon, 20 May 2013 13:15:00 +0000

Length (12 bits): indicates the number of bits of the Bit Map field, i.e., the number of TS in the HO ODUk link.  The TS granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's rate by the value of the Length field.  For example, for an HO ODU2 link, whose link rate is 10Gbps, the value of the Length field will be either 4 or 8 and the TS granularity will be either 2.5Gbps or 1.25Gbps, respectively.     

Irrespectively Yours,

John

> Sent: Friday, May 17, 2013 1:33 PM
> To: John E Drake
> Cc: Fatai Zhang; [email-masked];
> CCAMP; [email-masked]
> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709
> open issues)
> 
> John,
> 	I guess you haven't been paying attention!  The rewrite
> originated from Daniele, was tweaked by me and then fixed by Fatai.
> 
> > I think the original text is fine and your attempted re-write
> completely mangled its meaning.  The label is a bit vector whose length
> is equal to the ODUk rate / TSG.
> >
> > Irrespectively Yours,
> >
> > John
> >
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Lou Berger
> >> Cc: [email-masked]; CCAMP;
> >> draft- [email-masked]
> closure
> >> on Issue #48: "Document no explicit indication of TSG in the label"
> >> As I read the list, this issue will be resolved by making the
> >> following change to draft-ietf-ccamp-gmpls-signaling-g709v3.
> >>
> >> OLD
> >>   Note that the

---

From: Lou Berger <[email-masked]>
Date: Mon, 20 May 2013 14:43:13 -0400

John,
 There's still some ambiguity here.  How about:
On 5/20/2013 9:15 AM, John E Drake wrote:
> Length (12 bits): indicates the number of bits of the Bit Map field,
> i.e., the number of TS in the HO ODUk link.  The TS granularity,
> 1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's
> rate by the value of the Length field.  

Replace:
> For example, for an HO ODU2
> link, whose link rate is 10Gbps, the value of the Length field will
> be either 4 or 8 and the TS granularity will be either 2.5Gbps or
> 1.25Gbps, respectively.
> 
With:

   The values of 4 and 16 indicate a TS granularity of 2.5Gps, while
   the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps.

Lou

---

From: John E Drake <[email-masked]>
Date: Mon, 20 May 2013 19:18:45 +0000

I think that's a big mistake(tm).  If a new rate or TSG is introduced the RFC would need to be updated even though the encoding does not require it.

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Mon, 20 May 2013 19:28:35 +0000

Btw, what is the alleged ambiguity to which you refer?

Sent from my iPhone

---

From: Lou Berger <[email-masked]>
Date: Mon, 20 May 2013 16:41:33 -0400

On 5/20/2013 3:18 PM, John E Drake wrote:
> I think that's a big mistake(tm).  If a new rate or TSG is introduced
> the RFC would need to be updated even though the encoding does not
> require it.
> 

Well that's easily addressed, via something like:

Length (12 bits): indicates the number of bits of the Bit Map field,
i.e., the number of TS in the HO ODUk link.  The TS granularity,
1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's rate
by the value of the Length field.  In the context of [G709-2012], the
values of 4 and 16 indicate a TS granularity of 2.5Gps, and the values
2, 8, 32 and 80 indicate a TS granularity of 1.25Gps.

Lou

---

From: John E Drake <[email-masked]>
Date: Tue, 21 May 2013 02:30:30 +0000

What is behind your preoccupation with enumerating all possible combinations of length & TSG?  Do you have trouble with arithmetic?

Sent from my iPhone

---

From: Lou Berger <[email-masked]>
Date: Tue, 21 May 2013 08:37:09 -0400

John,

Really?  You're joking right?

As I said to Fatai:
   My feeling is that there have been too many "surprises" on the 709
   documents in areas that I thought were ... resolved by past
   discussions.  At this point, as co-chair and Document shepherd, I
   want to ensure that any open point on the documents are
   unambiguously closed and that past discussions (i.e., points of
   consensus) are 100% captured, so that we can smoothly move through
   the planned second LC and publication request.

The particular point of the ambiguity/implicit nature of determining TSG
from length has been brought up at least three times.  (Note, by others
in the WG -- this is not my concern.) Each time the consensus from the
discussion is to leave as is, but no or only minimal changes were made
to the document.  I opened the trac ticket to ensure that the consensus
was documented in the draft and that we don't have to yet again revisit
this topic -- which *is* my concern.

So, the revised text addresses your concern of not needing to redefine
the field for new 709 rate or TSGs, and it is sufficiently precise so
that non should misinterpret the current "implicit" specification of TSG.

Can we/you accept the revised "overly precise" text and move forward?

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 21 May 2013 09:16:57 -0400

All,

In the interest of moving this discussion quickly to closure, I spent
some time trying to come up with the full list of G.709 PT to G-PID
mappings.  In coming up with this list I tried to be consistent with
the last consensus point that I can identify on this topic (the
previously referenced July 2012 thread & presentation), which included:

A) Defining new G-PIDs for client types not identified by an assigned
G-PID (per
http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml)

B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a
G.709 payload type, and define new G-PIDs when reuse not possible.

C) No G-PID value for unused, reserved, or proprietary 709 Payload Type.

Here's what I've come up with:

    G.709
   Payload
    Type   G-PID   Type/Comment    LSP Encoding
    ====   =====   ==============  ===================
    0x01           No standard value
    0x02    49     CBRa            G.709 ODUk
    0x03    50     CBRb            G.709 ODUk
    0x04    32     ATM             G.709 ODUk
    0x05    TBA1   Framed GFP      G.709 ODUk
    0x06    ???    Is any valued needed?
    0x07    55     Ethernet PHY    G.709 ODUk (k=0)
                   (transparent    G.709 ODUk (k=3)
                   GFP)            G.709 ODUk (k=4)
    0x08    58     Fiber Channel   G.709 ODUk (k=2e)
    0x09    TBA1   Framed GFP      G.709 ODUk (k=2e)
    0x0A    TBA2   STM-1           G.709 ODUk (k=0)
    0x0B    TBA3   STM-4           G.709 ODUk (k=0)
    0x0C    58     Fiber Channel   G.709 ODUk (k=0)
    0x0D    58     Fiber Channel   G.709 ODUk (k=1)
    0x0E    58     Fiber Channel   G.709 ODUflex
    0x0F    58     Fiber Channel   G.709 ODUflex
    0x10    51     BSOT            G.709 ODUk
    0x11    52     BSNT            G.709 ODUk
    0x12    TBA4   InfiniBand      G.709 ODUflex
    0x13    TBA4   InfiniBand      G.709 ODUflex
    0x14    TBA4   InfiniBand      G.709 ODUflex
    0x15    TBA5   Serial Digital  G.709 ODUk (k=0)
                   Interface
    0x16    TBA6   Serial Digital  G.709 ODUk (k=1)
                   Interface/1.001
    0x17    TBA5   Serial Digital  G.709 ODUk (k=1)
                   Interface
    0x18    TBA6   Serial Digital  G.709 ODUflex
                   Interface/1.001
    0x19    TBA5   Serial Digital  G.709 ODUflex
                   Interface
    0x1A    56     SBCON/ESCON     G.709 ODUk (k=0)
                   (IANA to update Type field)
    0x1B    TBA7   DVB_ASI         G.709 ODUk (k=0)
    0x1C    58     Fiber Channel   G.709 ODUk
    0x20    47     G.709 ODU-2.5G  G.709 ODUk
                                     (k=2,3)
                   (IANA to update Type field)
            TBA8   G.709 ODU-1.25G G.709 ODUk
                                     (k=1,2,3)
    0x21    TBA8   G.709 ODU-1.25G G.709 ODUk
                                     (k=2,3,4)
            TBA9   G.709 ODU-Any   G.709 ODUk
                                   (k=2,3)
    0x55           No standard value
    0x66           No standard value
    0x80-0x8F      No standard value
    0xFD    TBA10  Null Test       G.709 ODUk
    0xFE    TBA11  Random Test     G.709 ODUk
    0xFF           No standard value

Note that there are a few differences with Fatai's list, which doesn't
format well in e-mail, but is available in the archive
http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html

Please speak up if you think the above is not aligned with prior
consensus or if you have an issue with any of the above.

Much thanks,
Lou

On 5/20/2013 5:09 AM, Fatai Zhang wrote:
> In addition, if people look at the full list that I provided, I think
> people can realize that RFC4328 (section 3.1.3) used the same approach
> as the current approach of this draft (ie., 1:1 mapping between GPIDs
> and payload types defined by G.709), ie., we are following what RFC4328
> did.
> 
>  
> 
> BTW, I am not sure if we need spend so much on discussing this point
> (because there is no issue to stick to the data plane by using the
> current approach of this draft).
> 
>  
> 
> We realize that it is safe to use 1:1 mapping approach to avoid some
> potential issues after investigation. We know this payload types have
> been defined by G.709 (data plane), so physically it is better to use
> 1:1 mapping approach.
> 
> For the potential issues I mentioned above, for example, we cannot use
> the existing 34 to represent 'STM-1' and 'STM-4 ', because it is
> impossible to differentiate which one is 'STM-1' or 'STM-4'. In
> addition, from the concept of payload type, we know that e.g, FC-100 is
> different from FC-800, right? So, it is better to assign different GPIDs
> to these different payload types defined by the data plane.
> 
>  
> 
> Furthermore, I think it is much cheaper to create new GPIDs in the
> control plane than in the data plane (these payload types will be
> carried in the OH).
> 
>  
> 
>  
> 
>  
> 
>  
> 
> Best Regards
> 
>  
> 
> Fatai
> 
>  
>

---

From: John E Drake <[email-masked]>
Date: Tue, 21 May 2013 20:23:37 +0000

Lou,

The question that has always been is whether signaling needed to include an explicit TSG filed and the answer has always been no because it can be derived from other fields.  The text I proposed makes that derivation explicit and unambiguous.  The additional text you are proposing adds neither clarity nor information.

Yours Irrespectively,

John

> Sent: Tuesday, May 21, 2013 5:37 AM
> To: John E Drake
> The particular point of the ambiguity/implicit nature of determining
> TSG from length has been brought up at least three times.  (Note, by
> others in the WG -- this is not my concern.) Each time the consensus
> from the discussion is to leave as is, but no or only minimal changes
> were made to the document.  I opened the trac ticket to ensure that the
> consensus was documented in the draft and that we don't have to yet
> again revisit this topic -- which *is* my concern.
> 
> > What is behind your preoccupation with enumerating all possible
> combinations of length & TSG?  Do you have trouble with arithmetic?
> >
> > Sent from my iPhone
> >
> >>> I think that's a big mistake(tm).  If a new rate or TSG is
> >>> introduced the RFC would need to be updated even though the
> encoding
> >>> does not require it.
> >>
> >> rate by the value of the Length field.  In the context of
> >> [G709-2012], the values of 4 and 16 indicate a TS granularity of
> >> 2.5Gps, and the values 2, 8, 32 and 80 indicate a TS granularity of
> 1.25Gps.
> >>
> >> Lou
> >>
> >>> Sent from my iPhone
> >>>
> >>>>> Length (12 bits): indicates the number of bits of the Bit Map
> >>>>> field, i.e., the number of TS in the HO ODUk link.  The TS
> >>>>> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing the
> >>>>> HO ODUk link's rate by the value of the Length field.
> >>>>
> >>>>
> >>>> Replace:
> >>>>> link, whose link rate is 10Gbps, the value of the Length field
> >>>>> will be either 4 or 8 and the TS granularity will be either
> >>>>>> Cc: Fatai Zhang;
> >>>>>> [email-masked];
> >>>>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was:
> Closing
> >>>>>> G.709 open issues)
> >>>>>>
> >>>>>> John,
> >>>>>> Issue #48="In signaling document section 6: Clarify related text
> >>>>>> [i.e., the OLD text] to unambiguously identify the relationship
> >>>>>> between label length and TSG."
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Lou
> >>>>>>
> >>>>>> completely mangled its meaning.  The label is a bit vector whose
> >>>>>> length is equal to the ODUk rate / TSG.
> >>>>>>>
> >>>>>>> Irrespectively Yours,
> >>>>>>>
> >>>>>>> John
> >>>>>>>
> >>>>>>>
> >>>>>>>> Subject: [CCAMP] Confirming plan for Issue #48: (Was: Closing
> >>>>>>>> G.709 open issues)
> >>>>>>>>
> >>>>>>>> Authors/WG,
> >>>>>>>> (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48).  I'd
> like
> >>>>>>>> to confirm my reading.
> >>>>>>>>
> >>>>>>>> type of the HO ODUk (i.e., TS granularity at 1.25Gbps or
> >>>>>>>> 2.5Gbps) since the HO ODUk type can be known from IF_ID
> >>>>>>>> RSVP_HOP Object. In some cases when there is no Link
> Management
> >>>>>>>> Protocol (LMP) or routing to make the two end points of the
> >>>>>>>> link to know the TSG, the TSG information used by another end
> >>>>>>>> can be deduced from the label format. For example, for HO ODU2
> >>>>>>>> link, the value of the length filed will be 4 or 8, which
> >>>>>>>> indicates the TS granularity is 2.5Gbps or 1.25Gbps,
> respectively.
> >>>>>>>>
> >>>>>>>> NEW
> >>>>>>>> Please note that the TS granularity of an HO ODUk can be
> >>>>>>>> inferred from the length of the label. The values of 4 and 16
> >>>>>>>> indicate a TS granularity of 2.5Gps, while the values 2, 8, 32
> >>>>>>>> and 80 indicate a
> >>>>>> TS
> >>>>>>>> granularity of 1.25Gps.
> >>>>>>>>
> >>>>>>>>> For point 1), "1" should be dropped and "7" should be
> >>>>>>>>> corrected to
> >>>>>>>> "8" in your proposed text.
> >>>>>>>>

---

From: Lou Berger <[email-masked]>
Date: Tue, 21 May 2013 20:38:16 -0400

John,

Great. It seems we agree that it shouldn't have been necessary to discuss 
this point so many times, and that the additional text doesn't change the 
field definition. It is informative narrative after all.

Now that said, can you live with the revised "overly precise" text so that 
we can move forward (and ensure we're not back here again)?

Lou

On May 21, 2013 4:23:37 PM John E Drake <[email-masked]> wrote:
> Lou,
>
> The question that has always been is whether signaling needed to include an 
> explicit TSG filed and the answer has always been no because it can be 
> derived from other fields.  The text I proposed makes that derivation 
> explicit and unambiguous.  The additional text you are proposing adds 
> neither clarity nor information.
>
> Yours Irrespectively,
>
> John
>

---

From: John E Drake <[email-masked]>
Date: Wed, 22 May 2013 00:45:12 +0000

It should be blindingly obvious to the informed reader that in the context of [G709-2012], the values of 4 and 16 indicate a TS granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps.

Yours Irrespectively,

John

> Sent: Tuesday, May 21, 2013 5:38 PM
> To: John E Drake
> Subject: RE: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709
> open issues)
> 
> John,
> 
> Great. It seems we agree that it shouldn't have been necessary to
> discuss this point so many times, and that the additional text doesn't
> change the field definition. It is informative narrative after all.
> 
> Now that said, can you live with the revised "overly precise" text so
> that we can move forward (and ensure we're not back here again)?
> 
> Lou
> 
> > The question that has always been is whether signaling needed to
> > include an explicit TSG filed and the answer has always been no
> > because it can be derived from other fields.  The text I proposed
> > makes that derivation explicit and unambiguous.  The additional text
> > you are proposing adds neither clarity nor information.
> >
> > Yours Irrespectively,
> >
> > John
> >
> > > Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing
> > > G.709 open issues) John, Really?  You're joking right?
> > > As I said to Fatai:
> > > from the discussion is to leave as is, but no or only minimal
> > > changes were made to the document.  I opened the trac ticket to
> > > ensure that the consensus was documented in the draft and that we
> > > don't have to yet again revisit this topic -- which *is* my
> concern.
> > > So, the revised text addresses your concern of not needing to
> > > redefine the field for new 709 rate or TSGs, and it is sufficiently
> > > precise so that non should misinterpret the current "implicit"
> > > specification of TSG.
> > > >> HO ODUk link's rate by the value of the Length field.  In the
> > > >> context of [G709-2012], the values of 4 and 16 indicate a TS
> > > >> granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a
> > > >> TS granularity of
> > > 1.25Gps.
> > > >>
> > > >> Lou
> > > >>
> > > >>> Sent from my iPhone
> > > >>>
> > > >>>>> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing
> > > >>>>> the HO ODUk link's rate by the value of the Length field.
> > > >>>>
> > > >>>>
> > > >>>> Replace:
> > > >>>>  The values of 4 and 16 indicate a TS granularity of 2.5Gps,
> > > >>>> while the values 2, 8, 32 and 80 indicate a TS granularity of
> 1.25Gps.
> > > >>>>
> > > >>>> Lou
> > > >>>>
> > > >>>>
> > > >>>>> Irrespectively Yours,
> > > >>>>>
> > > >>>>> John
> > > >>>>>
> > > >>>>>
> > > >>>>>> Issue #48="In signaling document section 6: Clarify related
> > > >>>>>> text [i.e., the OLD text] to unambiguously identify the
> > > >>>>>> relationship between label length and TSG."
> > > >>>>>>
> > > >>>>>> Thanks,
> > > >>>>>> Lou
> > > >>>>>>
> > > >>>>>> completely mangled its meaning.  The label is a bit vector
> > > >>>>>> whose length is equal to the ODUk rate / TSG.
> > > >>>>>>>
> > > >>>>>>> Irrespectively Yours,
> > > >>>>>>>
> > > >>>>>>> John
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>> From: [email-masked]
> > > >>>>>>>> [mailto:[email-masked]]
> > > On
> > > >>>>>>>> Behalf Of Lou Berger
> > > >>>>>>>> on Issue #48: "Document no explicit indication of TSG in
> > > >>>>>>>> the
> > > label"
> > > >>>>>>>> As I read the list, this issue will be resolved by making
> > > >>>>>>>> the following change to draft-ietf-ccamp-gmpls-signaling-
> g709v3.
> > > >>>>>>>>
> > > >>>>>>>> OLD
> > > >>>>>>>> Note that the
> > > >>>>>>>> Length field in the label format MAY be used to indicate
> > > >>>>>>>> the
> > > TS
> > > >>>>>>>> link to know the TSG, the TSG information used by another
> > > >>>>>>>> end can be deduced from the label format. For example, for
> > > >>>>>>>> HO ODU2 link, the value of the length filed will be 4 or
> 8,
> > > >>>>>>>> which indicates the TS granularity is 2.5Gbps or 1.25Gbps,
> > > respectively.
> > > >>>>>>>>
> > > >>>>>>>> NEW
> > > >>>>>>>> inferred from the length of the label. The values of 4 and
> > > >>>>>>>> 16 indicate a TS granularity of 2.5Gps, while the values
> 2,
> > > >>>>>>>> 8, 32 and 80 indicate a
> > > >>>>>> TS
> > > >>>>>>>> granularity of 1.25Gps.
> > > >>>>>>>>

---

From: Lou Berger <[email-masked]>
Date: Wed, 22 May 2013 13:28:41 -0400

I'm empathetic with the addition, but suspect it's best not to put the
first 10 words in the draft...

Lou

---

From: John E Drake <[email-masked]>
Date: Wed, 22 May 2013 18:00:49 +0000

Bummer

Sent from my iPhone

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 23 May 2013 00:55:04 +0000

Hi Lou and John,

Thanks for your discussion on providing the proposed text.

However, I am lost by the discussion. 

What is the final proposed text? I hope someone can finalize it.

I think it is time to conclude the discussion on this point (the original point 1). 

Best Regards

Fatai

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Thursday, May 23, 2013 2:01 AM
To: Lou Berger
Cc: Fatai Zhang; CCAMP
Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues)

Bummer

Sent from my iPhone

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 23 May 2013 01:13:40 +0000

Hi Lou and all,

I would like to double check again on the original point 2.

I would assume the WG is happy with the proposed approach and then conclude the discussion on point 2 if there is no more comment until this Friday.

Note that I think more people have shown their support on the proposed approach.

Best Regards

Fatai

From: Fatai Zhang [mailto:[email-masked]]
Sent: Monday, May 20, 2013 5:09 PM
To: Lou Berger
Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; [email-masked]
Subject: RE: R: Closing G.709 open issues

Hi Lou,

I think my mail on May 13rd may have answered your following comments. My response quoted as follows.

In addition, if people look at the full list that I provided, I think people can realize that RFC4328 (section 3.1.3) used the same approach as the proposed approach (ie., 1:1 mapping between GPIDs and payload types defined by G.709), ie., we are following what RFC4328 did.

BTW, I am not sure if we need spend so much time on discussing this point (because there is no issue to stick to the data plane by using the proposed approach).

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Friday, May 17, 2013 11:16 PM
To: Fatai Zhang
Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; [email-masked]
Subject: Re: R: Closing G.709 open issues

Fatai,

publication request.

Much thanks,

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 22 May 2013 21:27:54 -0400

drop the OLD text (identified in the trac issue) & replace Length field
definition with:

>> TS granularity of 1.25Gps.

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 22 May 2013 21:41:20 -0400

Fatai,
	I think you missed the following:

http://www.ietf.org/mail-archive/web/ccamp/current/msg14861.html

> consensus or if you have an issue with any of the above.

(probably best to respond to that message if you have a comment on it.)

Lou

On 5/22/2013 9:13 PM, Fatai Zhang wrote:
> I would assume the WG is happy with the proposed approach and then
> conclude the discussion on point 2 if there is no more comment until
> this Friday.
> 
>  
> 
> *From:*Fatai Zhang [mailto:[email-masked]]
> *Sent:* Monday, May 20, 2013 5:09 PM
> *To:* Lou Berger
> *Cc:* BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP;
> *Subject:* RE: R: Closing G.709 open issues
> 
>  
> 
> Hi Lou,
> 
>  
> 
> I think my mail on May13rd may have answered your following comments. My
> response quoted as follows.
> 
>  
> 
> as the proposedapproach (ie., 1:1 mapping between GPIDs and payload
> types defined by G.709), ie., we are following what RFC4328 did.
> 
>  
> 
> BTW, I am not sure if we need spend so much time on discussing this
> point (because there is no issue to stick to the data plane by using the
> proposedapproach).
> 
>  
>

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 23 May 2013 02:05:54 +0000

Hi Lou,

I really missed this mail.

I will respond there.

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, May 23, 2013 9:41 AM
To: Fatai Zhang
Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; [email-masked]
Subject: Re: Closing Issue #49 (Was: Re: R: Closing G.709 open issues)

Fatai,

Lou

---

From: John E Drake <[email-masked]>
Date: Thu, 23 May 2013 02:10:09 +0000

Fatai,

Length (12 bits): indicates the number of bits of the Bit Map field, i.e., the number of TS in the HO ODUk link.  The TS granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's rate by the value of the Length field.  In the context of [G709-2012], the values of 4 and 16 indicate a TS granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps.

Yours Irrespectively,

John

> Sent: Wednesday, May 22, 2013 5:55 PM
> To: John E Drake; Lou Berger
> Cc: CCAMP
> >> It should be blindingly obvious to the informed reader that in the
> granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a TS
> granularity of 1.25Gps.
> >>
> >> Yours Irrespectively,
> >>
> >> John
> >>
> >>> Subject: RE: [CCAMP] Confirming plan for Issue #48: (Was: Closing
> >>> G.709 open issues)
> >>>
> >>> John,
> >>>
> >>> discuss this point so many times, and that the additional text
> >>> doesn't change the field definition. It is informative narrative
> after all.
> >>>
> >>> Now that said, can you live with the revised "overly precise" text
> >>> so that we can move forward (and ensure we're not back here again)?
> >>>
> >>> Lou
> >>>
> >>>> makes that derivation explicit and unambiguous.  The additional
> >>>> text you are proposing adds neither clarity nor information.
> >>>>
> >>>> Yours Irrespectively,
> >>>>
> >>>> John
> >>>>
> >>>>> redefine the field for new 709 rate or TSGs, and it is
> >>>>> sufficiently precise so that non should misinterpret the current
> "implicit"
> >>>>> specification of TSG.
> >>>>>>>>>>> originated from Daniele, was tweaked by me and then fixed
> by
> >>>>> Fatai.
> >>>>>>>>>>>

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 23 May 2013 02:35:14 +0000

Hi Lou,

I incorporated your proposal into my table to facilitate the readers.

I think you still insist on reusing some existing G-PIDs like 58, 56.  For 0x04, why you think that RFC4328 does not cover it (ie., G-PID=54)?

Technically, I am not convince by your proposal, but I would like to reserve my opinion for your same motivation (ie., to conclude the discussion as soon as possible).

Any opinions on Lou's proposal from the WG? I will update the signaling draft based on Lou's proposal if there is no comment on Lou's proposal.

Note that all the new G-PID values will be re-ordered with TBA.

G-PID

LSP Encoding

Note

0x01

None

Not needed

0x02

49

G.709 ODUk, G.709 OCh

0x03

50

G.709 ODUk

ditto

0x04

32

SDH, G.709 ODUk

ditto

0x05

54

or

TBA (Suggested by Lou)

G.709 ODUk (and SDH)

G-PIDs defined in RFC4328 for framed GFP

0x06

None

0x07

61(TBA)

Or 55(Suggested by Lou)

G.709 ODUk (k=0,3,4)

*      1000BASE-X into OPU0, see clauses 17.7.1 and 17.7.1.1

*      40GBASE-R into OPU3, see clauses 17.7.4 and 17.7.4.1

*      100GBASE-R into OPU4, see clauses 17.7.5 and 17.7.5.1

0x08

62(TBA)

Or 58(Suggested by Lou)

G.709 ODUk (k=2e)

ditto

0x09

63(TBA)

G.709 ODUk (k=2)

ditto

0x0A

64(TBA)

G.709 ODUk (k=0)

ditto

0x0B

65(TBA)

G.709 ODUk (k=0)

ditto

0x0C

66(TBA)

Or 58(Suggested by Lou)

G.709 ODUk (k=0)

ditto

0x0D

67(TBA)

Or 58(Suggested by Lou)

G.709 ODUk (k=1)

ditto

0x0E

68(TBA)

Or 58(Suggested by Lou)

G.709 ODUflex

ditto

0x0F

69(TBA)

Or 58(Suggested by Lou)

G.709 ODUflex

ditto

0x10

51

G.709 ODUk

0x11

52

G.709 ODUk

ditto

0x12

70(TBA)

G.709 ODUflex

0x13

71(TBA)

G.709 ODUflex

ditto

0x14

72(TBA)

G.709 ODUflex

ditto

0x15

73(TBA)

G.709 ODUk (k=0)

ditto

0x16

74(TBA)

G.709 ODUk (k=1)

ditto

0x17

75(TBA)

G.709 ODUk (k=1)

ditto

0x18

76(TBA)

G.709 ODUflex

ditto

0x19

77(TBA)

G.709 ODUflex

ditto

0x1A

78(TBA)

Or 56(Suggested by Lou)

G.709 ODUk (k=0)

ditto

0x1B

79(TBA)

G.709 ODUk (k=0)

ditto

0x20

47

G.709 ODUk

0x21

59/60(TBA)

G.709 ODUk

55

None

Not needed

Not available (Note 2)

66

None

Not needed

Not available (Note 2)

80-8F

None

Not needed

FD

None

Or TBA(Suggested by Lou)

Not needed

FE

None

Or TBA(Suggested by Lou)

Not needed

FF

None

Not needed

Not available (Note 2)

Best Regards

Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Tuesday, May 21, 2013 9:17 PM
To: CCAMP
Cc: [email-masked]
Subject: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)

All,

G-PID (per

    G.709

   Payload

    0x01           No standard value

    0x02    49     CBRa            G.709 ODUk

    0x03    50     CBRb            G.709 ODUk

    0x04    32     ATM             G.709 ODUk

                   GFP)            G.709 ODUk (k=4)

    0x10    51     BSOT            G.709 ODUk

    0x11    52     BSNT            G.709 ODUk

                   Interface

                   Interface/1.001

                   Interface

                   Interface/1.001

                   Interface

                                     (k=2,3)

                                     (k=1,2,3)

                                     (k=2,3,4)

                                   (k=2,3)

    0x55           No standard value

    0x66           No standard value

    0xFF           No standard value

Much thanks,

Lou

> I think my mail on March 13rd may have answered your following comments.

> My response quoted as follows.

CCAMP mailing list

[email-masked]

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 23 May 2013 02:38:40 +0000

Hi Lou,

An typed error should be corrected:

For 0x05, why you think that RFC4328 does not cover it (ie., G-PID=54)?

Best Regards

Fatai

From: Fatai Zhang
Sent: Thursday, May 23, 2013 10:35 AM
To: 'Lou Berger'; CCAMP
Cc: [email-masked]
Subject: RE: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)

Hi Lou,

G-PID

LSP Encoding

Note

0x01

None

Not needed

0x02

49

G.709 ODUk, G.709 OCh

0x03

50

G.709 ODUk

ditto

0x04

32

SDH, G.709 ODUk

ditto

0x05

54

or

TBA (Suggested by Lou)

G.709 ODUk (and SDH)

0x06

None

0x07

61(TBA)

Or 55(Suggested by Lou)

G.709 ODUk (k=0,3,4)

0x08

62(TBA)

Or 58(Suggested by Lou)

G.709 ODUk (k=2e)

ditto

0x09

63(TBA)

G.709 ODUk (k=2)

ditto

0x0A

64(TBA)

G.709 ODUk (k=0)

ditto

0x0B

65(TBA)

G.709 ODUk (k=0)

ditto

0x0C

66(TBA)

Or 58(Suggested by Lou)

G.709 ODUk (k=0)

ditto

0x0D

67(TBA)

Or 58(Suggested by Lou)

G.709 ODUk (k=1)

ditto

0x0E

68(TBA)

Or 58(Suggested by Lou)

G.709 ODUflex

ditto

0x0F

69(TBA)

Or 58(Suggested by Lou)

G.709 ODUflex

ditto

0x10

51

G.709 ODUk

0x11

52

G.709 ODUk

ditto

0x12

70(TBA)

G.709 ODUflex

0x13

71(TBA)

G.709 ODUflex

ditto

0x14

72(TBA)

G.709 ODUflex

ditto

0x15

73(TBA)

G.709 ODUk (k=0)

ditto

0x16

74(TBA)

G.709 ODUk (k=1)

ditto

0x17

75(TBA)

G.709 ODUk (k=1)

ditto

0x18

76(TBA)

G.709 ODUflex

ditto

0x19

77(TBA)

G.709 ODUflex

ditto

0x1A

78(TBA)

Or 56(Suggested by Lou)

G.709 ODUk (k=0)

ditto

0x1B

79(TBA)

G.709 ODUk (k=0)

ditto

0x20

47

G.709 ODUk

0x21

59/60(TBA)

G.709 ODUk

55

None

Not needed

Not available (Note 2)

66

None

Not needed

Not available (Note 2)

80-8F

None

Not needed

FD

None

Or TBA(Suggested by Lou)

Not needed

FE

None

Or TBA(Suggested by Lou)

Not needed

FF

None

Not needed

Not available (Note 2)

Best Regards

Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Tuesday, May 21, 2013 9:17 PM
To: CCAMP
Cc: [email-masked]
Subject: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)

All,

G-PID (per

    G.709

   Payload

    0x01           No standard value

    0x02    49     CBRa            G.709 ODUk

    0x03    50     CBRb            G.709 ODUk

    0x04    32     ATM             G.709 ODUk

                   GFP)            G.709 ODUk (k=4)

    0x10    51     BSOT            G.709 ODUk

    0x11    52     BSNT            G.709 ODUk

                   Interface

                   Interface/1.001

                   Interface

                   Interface/1.001

                   Interface

                                     (k=2,3)

                                     (k=1,2,3)

                                     (k=2,3,4)

                                   (k=2,3)

    0x55           No standard value

    0x66           No standard value

    0xFF           No standard value

Much thanks,

Lou

CCAMP mailing list

[email-masked]

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 23 May 2013 02:45:16 +0000

Lou and John,

Thanks. 

Happy to see that you both provided the same proposed text. 

Best Regards

Fatai

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Thursday, May 23, 2013 10:10 AM
To: Fatai Zhang; Lou Berger
Cc: CCAMP
Subject: RE: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues)

Fatai,

Yours Irrespectively,

John

---

From: Lou Berger <[email-masked]>
Date: Thu, 23 May 2013 12:14:36 -0400

Fatai,
	Do we really need to reopen debate on a topic the WG discussed and
closed last summer?  (i.e., to handle G.709 client adaptation just as we
do for every other technology.)

I do agree that some new G-PID assignments were missed in the draft that
went to LC, but filling in the list doesn't automatically mean that the
WG needs to reopen debate on adaptation approaches.

Assuming we don't need to reopen the pre-LC debate from last summer, and
with respect to the list I sent out, I do agree the WG needs to:

A) Ensure that the list doesn't have unneeded new G-PIDs (i.e., reuses
the same/existing G-PIDs wherever possible.)

B) Identifies the "right" G-PID per payload type, and doesn't have any
other technical errors

C) Doesn't conflict with past WG decisions/discussions.

>From your mails I see the following comment on (A):

> For 0x05, why you think that RFC4328 does not cover it (ie., G-PID=54)?

G-PID 54, per IANA, is currently defined as "Ethernet MAC (framed GFP)".
 Per G.709, PT=0x05 maps to "GFP mapping, see clause 17.4" and looking
at 17.4 there is no restriction on what is carried in GFP frames.  So it
seems that PT=0x05 can't be limited to just "Ethernet MAC (framed GFP)".

Are you suggesting changing the type description of G-PID 54 to just
"Framed GFP", or including G-PID 54 as an additional possibility for
PT=0x05?

The latter seems to be a valid addition/correction.  The former may be
problematic for existing implementations, so we'll need to discuss more
broadly if that's the direction you want to head.

All/ (WG),

Again, please speak up if you think the above is not aligned with prior
consensus or if you have an issue with any of the above.

Lou

On 5/22/2013 10:35 PM, Fatai Zhang wrote:
> I think you still insist on reusing some existing G-PIDs like 58, 56.
>  For 0x04, why you think that RFC4328 does not cover it (ie., G-PID=54)?
> 
>  
> 
> Technically, I am not convince by your proposal, but I would like to
> reserve my opinion for your same motivation (ie., to conclude the
> discussion as soon as possible).
> 
>  
> 
> Any opinions on Lou’s proposal from the WG? I will update the signaling
> draft based on Lou’s proposal if there is no comment on Lou’s proposal.
> 
>  
> 
> Or55(Suggested by Lou)
> Or58(Suggested by Lou)
> Or58(Suggested by Lou)
> Or58(Suggested by Lou)
> Or58(Suggested by Lou)
> Or58(Suggested by Lou)
> Or56(Suggested by Lou)
> OrTBA(Suggested by Lou)
> OrTBA(Suggested by Lou)

---

From: Khuzema Pithewan <[email-masked]>
Date: Thu, 23 May 2013 19:15:51 +0000

Hi Lou,

-> C) No G-PID value for unused, reserved, or proprietary 709 Payload Type.

Let say some vendor uses reserved (80-8F, which will never be standardized by ITU, as per Note4 in Table 15-8) payload code point and uses some GPid 'x' in Control plane for that code point. Now if in future, Control plane defines x for some other client. 
There will be backward compatibility issues.

Since it is clearly mentioned that these 16 code points in dataplane, will not standardized, is a standardization in way, which must be followed up in control plane by reserving 16 GPids for the purpose.

Regds
Khuzema

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, May 21, 2013 6:47 PM
To: CCAMP
Cc: [email-masked]
Subject: Closing Issue #49 (Was: Re: R: Closing G.709 open issues)

All,

    G.709
   Payload

Much thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 23 May 2013 17:07:05 -0400

On 5/23/2013 3:15 PM, Khuzema Pithewan wrote:
> Let say some vendor uses reserved (80-8F, which will never be
> standardized by ITU, as per Note4 in Table 15-8) payload code point
> and uses some GPid 'x' in Control plane for that code point. Now if
> in future, Control plane defines x for some other client.
> 

Khuzema,

	I agree.  Vendors have always used (and continue to use)  standard code
points for proprietary purposes at their own peril.  There is nothing
new or unique about this in the context of the documents we're discussing.

Another way to look at it is to ask/answer the following: What about
this draft (supporting [G709-2012]) is different from [RFC4328]
(supporting g709-2001) or any other technology supported by GMPLS that
has experimental, reserved, and/or unavailable client types?

> 
> Since it is clearly mentioned that these 16 code points in dataplane,
> will not standardized, is a standardization in way, 

> which must be
> followed up in control plane by reserving 16 GPids for the purpose.

Why?  [RFC4328] didn't standardize G-PIDs for the following G.709-2001
defined PTs:

  PT      Interpretation
0x01      Experimental mapping \
0x55      Not available
0x66      Not available
0x80-0x8F Reserved codes for proprietary use
0xFF      Not available

Are you just trying to be exhaustive in your definitions, or do you have
an actual use case?  If the latter, can you elaborate on your desired use?

BTW you might want to look at the current IANA G-PID assignments before
answering.  I suspect you'll find that you can address your concerns
using existing assignments.

Thanks,
Lou

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 24 May 2013 01:01:07 +0000

Hi Lou,

Fine, thanks for your explanation.

As I said, I will update the signaling draft based on your proposal if there are no further comments.

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, May 24, 2013 12:15 AM
To: Fatai Zhang
Cc: CCAMP; [email-masked]
Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)

Fatai,

All/ (WG),

Lou

On 5/22/2013 10:35 PM, Fatai Zhang wrote:
> Any opinions on Lou's proposal from the WG? I will update the signaling
> draft based on Lou's proposal if there is no comment on Lou's proposal.
> 
>  
>

---

From: Khuzema Pithewan <[email-masked]>
Date: Fri, 24 May 2013 09:32:22 +0000

Hi Lou,

-> Are you just trying to be exhaustive in your definitions, or do you have an actual use case?  If the latter, can you elaborate on your desired use?

There is no actual usecase, rather intent is to align dataplane spec with control plane spec.

In reality, there may not arise any backward compatibility issue in foreseeable future, because GPid range is very large (16 bits) and vendor specific client payload may choose to use very high Gpid value, where standard defined GPid may not reach.

Having said that, I am not sure, why RFC 3471 defines 4 Gpid values (1-4) as reserved. What purpose does it serve? 

Either we define reserved values that underlying dataplane defines, or we don't define at all. 

 If we have convention of defining reserved GPids, then why not match it with data plane spec. 

However, I believe defining or not defining reserved value, is not going to have any material impact on the way standard will be implemented. I am fine either way!

Regards
Khuzema

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, May 24, 2013 2:37 AM
To: Khuzema Pithewan
Cc: CCAMP; [email-masked]
Subject: Re: Closing Issue #49 (Was: Re: R: Closing G.709 open issues)

On 5/23/2013 3:15 PM, Khuzema Pithewan wrote:
> and uses some GPid 'x' in Control plane for that code point. Now if in 
> future, Control plane defines x for some other client.
> 

Khuzema,

	I agree.  Vendors have always used (and continue to use)  standard code points for proprietary purposes at their own peril.  There is nothing new or unique about this in the context of the documents we're discussing.

Another way to look at it is to ask/answer the following: What about this draft (supporting [G709-2012]) is different from [RFC4328] (supporting g709-2001) or any other technology supported by GMPLS that has experimental, reserved, and/or unavailable client types?

> followed up in control plane by reserving 16 GPids for the purpose.

Why?  [RFC4328] didn't standardize G-PIDs for the following G.709-2001 defined PTs:

  PT      Interpretation

Are you just trying to be exhaustive in your definitions, or do you have an actual use case?  If the latter, can you elaborate on your desired use?

BTW you might want to look at the current IANA G-PID assignments before answering.  I suspect you'll find that you can address your concerns using existing assignments.

Thanks,
Lou

> ers.xml)
>> people can realize that RFC4328 (section 3.1.3) used the same 
>> approach as the current approach of this draft (ie., 1:1 mapping 
>> between GPIDs and payload types defined by G.709), ie., we are 
>> following what RFC4328 did.
>>
>>  
>>
>> =====================================================================
>> =================================================
>>
>> For the potential issues I mentioned above, for example, we cannot 
>> use the existing 34 to represent 'STM-1' and 'STM-4 ', because it is 
>> addition, from the concept of payload type, we know that e.g, FC-100 
>> is different from FC-800, right? So, it is better to assign different 
>> GPIDs to these different payload types defined by the data plane.
>>
>>  
>>
>> want

---

From: Lou Berger <[email-masked]>
Date: Fri, 24 May 2013 09:15:25 -0400

Fatai,

Just to be clear, the following covers your correction:

    G.709
   Payload
    Type   G-PID   Type/Comment    LSP Encoding
    ====   =====   ==============  ===================
    0x05    TBA1   Framed GFP      G.709 ODUk
            54     Ethernet MAC    G.709 ODUk
                   (framed GFP)

Right?

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Fri, 24 May 2013 09:24:16 -0400

Khuzema,
	Glad to hear there's no actual use case / issue to be addressed.

As to your general comments/observations, my perspective is that given
the generic cross-technology nature of GMPLS there often isn't a direct
1:1 mapping of switching technology semantics to GMPLS semantics.

As to your specific (theoretical) concern, I think you might have missed
the following IANA controlled (and RFC4328 defined) ranges:

  31744-32767 Experimental Usage/temporarily
  32768-65535 Reserved

Lou

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Fri, 24 May 2013 15:54:46 +0000

Hi,

Please take care anyway this solution does not consider two cases:

G.7041 and G.709, defines respectively:

10GbE --> GFP-F (G.7041, Table 6-3: UPI=0x13  [ Frame-mapped 64B/66B encoded
Ethernet, including the Ethernet frame preamble ])

10GbE--> extended OPU2/ODU2 (G.709, Table 15-8: PT=0x09 [ GFP mapping into Extended
OPU2 payload, see clause 17.4.1 ])

Please not that this is not the mapping using UPI=0x01 and PT=0x05

Best Regards

Sergio

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Lou Berger
Inviato: venerdì 24 maggio 2013 15.15
A: Fatai Zhang
Cc: CCAMP; [email-masked]
Oggetto: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)

Fatai,

    G.709
   Payload

Right?

Thanks,
Lou

---

From: Khuzema Pithewan <[email-masked]>
Date: Fri, 24 May 2013 16:27:46 +0000

Thanks Lou. Appreciate the pointer to RFC4328. I did miss it.

Regards
Khuzema

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, May 24, 2013 6:54 PM
To: Khuzema Pithewan
Cc: CCAMP; [email-masked]
Subject: Re: Closing Issue #49 (Was: Re: R: Closing G.709 open issues)

Khuzema,

As to your general comments/observations, my perspective is that given the generic cross-technology nature of GMPLS there often isn't a direct
1:1 mapping of switching technology semantics to GMPLS semantics.

As to your specific (theoretical) concern, I think you might have missed the following IANA controlled (and RFC4328 defined) ranges:

Lou

On 5/24/2013 5:32 AM, Khuzema Pithewan wrote:
>> Note that there are a few differences with Fatai's list, which 
>> doesn't format well in e-mail, but is available in the archive 
>>> In addition, if people look at the full list that I provided, I 
>>> think people can realize that RFC4328 (section 3.1.3) used the same 
>>> ====================================================================
>>> = =================================================
>>>
>>> potential issues after investigation. We know this payload types 
>>> have been defined by G.709 (data plane), so physically it is better 
>>> to use
>>> 1:1 mapping approach.
>>>
>>> is different from FC-800, right? So, it is better to assign 
>>> different GPIDs to these different payload types defined by the data plane.
>>>
>>>  
>>>

---

From: Lou Berger <[email-masked]>
Date: Fri, 24 May 2013 12:33:00 -0400

Sergio,

> Ethernet, including the Ethernet frame preamble ])

Cool, yet another way to encode Ethernet over GFP. (Pointing to the
G.7041 UPI was very helpful, the draft will need to capture that!)  What
PT is used for this?  Are there other client types missing/that you
think are missing?

> OPU2 payload, see clause 17.4.1 ])

Is this a different case? If yes, how so? (Do you have a data plane
reference?)

Thanks,
Lou

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Tue, 28 May 2013 15:02:35 +0000

Hi Lou,

See below for my notes .
I attached the Fatai's doc for GPID mapping with possible suggested addon.

Thanks

Sergio

-----Messaggio originale-----
Da: Lou Berger [mailto:[email-masked]] 
Inviato: venerdì 24 maggio 2013 18.33
A: BELOTTI, SERGIO (SERGIO)
Cc: CCAMP; [email-masked]; Fatai Zhang
Oggetto: Re: R: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)

Sergio,

SB> In G.7041 Table 6-3 - User payload identifiers for GFP client frames  define the UPI values.
 UPI is setup according to the transported signal type.
Here we can see there is another form of Ethernet mapping via GFP and  ODU2 signals can carry  diverse payloads including diverse GFP-F mapped Ethernet.
I think the best we can do would be to define GPID values for all possible/meaningful combinations of PT/UPI values where GFP is used to encapsulate the client signal.

What I have indicated here are just two possible addon: one is already considered in the file provided by Fatai , the other is the one form G.7041.
Attached the doc from Fatai, updated (in yellow) with the new GFP Ethernet mapping possibility.

My suggestion would be to define GPID values for all possible/meaningful combinations of PT/UPI values where GFP is used to encapsulate the client signal.

SB> For ODU2 in OTN there is two possible PT options for 10GbE and are
 PT= 0x05 (ODU2) | PT = 0x09 (extended ODU2)

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 28 May 2013 11:48:35 -0400

Sergio,
	See below.

Also, can you just put your comments/discussion points in mail rather
than a word file?  I don't think the use of word is providing any value
in this context.

> Attached the doc from Fatai, updated (in yellow) with the new GFP Ethernet mapping possibility.

Unless I misread it, you didn't propose any new G-PIDs.

> 
> 
> My suggestion would be to define GPID values for all
> possible/meaningful combinations of PT/UPI values where GFP is used
> to encapsulate the client signal.
> 

If you want to define additional types, please propose them!  If there
are no specifics, there's nothing for the WG to discuss/agree to.

>  PT= 0x05 (ODU2) | PT = 0x09 (extended ODU2)

Okay, sounds like a new G-PID type (TBA12 below). So here's the updated
table as I understand it:

    G.709
   Payload
            TBA12  64B/66B GFP-F   G.709 ODUk (k=2)
                   Ethernet
            TBA12  64B/66B GFP-F   G.709 ODUk (k=2e)
                   Ethernet

What *specific* changes/additions do you think are needed? (Please add
to this table and NOT the word file, once we have agreement on e-mail
the result can be directly inserted into the draft.)

Lou

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Tue, 28 May 2013 16:12:16 +0000

Lou,

Obviously opinion are opinion since anyone can see things in a different way: I thought to do a favour to include suggestion in the word file used during the discussion by Fatai...

Anyway below my notes.

Sergio

-----Messaggio originale-----
Da: Lou Berger [mailto:[email-masked]] 
Inviato: martedì 28 maggio 2013 17.49
A: BELOTTI, SERGIO (SERGIO)
Cc: CCAMP; [email-masked]; Fatai Zhang; Beller, Dieter (Dieter)
Oggetto: Re: R: R: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)

Sergio,
	See below.

SB> In fact you misread

SB> I've attached the file for that as clearly explained.

    G.709
   Payload

SB> NO, the changes you have done capture my suggestion.

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 28 May 2013 12:34:20 -0400

>> What *specific* changes/additions do you think are needed?
>>

Excellent.  This comment is now addressed/closed.

Authors,

Please update the draft based on the table included below, as well as
the issue 48 discussion.  If there are other corrections/additions, they
can be picked up as they come in, or as part of the 2nd LC.

Lou