Re: [CCAMP] Closing G.709 open issues

[Lou Berger <[e-mail]>]

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.
>
> I don't think we need discuss this anymore.

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

On 5/14/2013 1:53 AM, Fatai Zhang wrote:
> 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:[e-mail]] 
> Sent: Monday, May 13, 2013 3:45 PM
> To: Fatai Zhang; Lou Berger
> Cc: Daniele Ceccarelli; CCAMP; [e-mail]; [e-mail]
> Subject: R: Closing G.709 open issues
> 
> 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 [phone]
> -----Messaggio originale-----
> Da: Fatai Zhang [mailto:[e-mail]] 
> Inviato: lunedì 13 maggio 2013 5.33
> A: Lou Berger
> Cc: Daniele Ceccarelli; CCAMP; [e-mail]; [e-mail]
> Oggetto: RE: Closing G.709 open issues
> 
> 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:[e-mail]] 
> Sent: Friday, May 10, 2013 8:51 PM
> To: Fatai Zhang
> Cc: Daniele Ceccarelli; CCAMP; [e-mail]; [e-mail]
> Subject: Re: Closing G.709 open issues
> 
> 
> 
> On 5/9/2013 9:41 PM, Fatai Zhang wrote:
>> Hi Lou,
>>
>> 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
>>      -----       ----------             -----------------
>>    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)?
> 
>>    61(TBA)     PCS                    G.709 ODUk (k=0)
>>    62(TBA)     FC-1200                G.709 ODUk (k=2e)
> Why not us existing G-PID 58?
> 
>>    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)
> Why not us existing G-PID 34?
> 
>>    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
> Why not us existing G-PID 58?
> 
>>    70(TBA)     IB SDR                 G.709 ODUflex
>>    71(TBA)     IB DDR                 G.709 ODUflex
>>    72(TBA)     IB QDR                 G.709 ODUflex
> Can these be one value with rate implying SDR/DDR/QDR?
> 
>>    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
> 
> 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?
> 
>>    79(TBA)     DVB_ASI                G.709 ODUk (k=0)
>>
>>
>>
>>
> 
> Thanks,
> Lou
> 
> 
> 
> 
> 
>