Re: [CCAMP] Closing G.709 open issues

[Daniele Ceccarelli <[e-mail]>]

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


>-----Original Message-----
>From: Lou Berger [mailto:[e-mail]] 
>Sent: martedì 14 maggio 2013 16.01
>To: Fatai Zhang
>Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; 
>[e-mail]; 
>[e-mail]
>Subject: Re: Closing G.709 open issues
>
>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-paramet
>> ers.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
>> 
>> 
>> 
>> 
>> 
>> 
>