Re: [CCAMP] R: Closing G.709 open issues

[Lou Berger <[e-mail]>]

Sergio/Fatai,

On 5/15/2013 7:54 AM, BELOTTI, SERGIO (SERGIO) wrote:
> 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
> 
> 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.
> 
> 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.

> 
> 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):
> 
>     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)
> 

> 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

> Hope this can help.
> 
> Best Regards
> Sergio
> 
> Belotti Sergio-  System Architect
> ALCATE-LUCENT  Optics Division
> via Trento 30 Vimercate (MB) - Italy
> phone [phone]
> 
> -----Messaggio originale-----
> Da: Lou Berger [mailto:[e-mail]] 
> Inviato: mercoledì 15 maggio 2013 13.22
> A: Daniele Ceccarelli; Fatai Zhang
> Cc: BELOTTI, SERGIO (SERGIO); CCAMP; [e-mail]; [e-mail]
> Oggetto: RE: Closing G.709 open issues
> 
> Daniele,
> 
> On May 15, 2013 4:20:25 AM Daniele Ceccarelli 
> <[e-mail]> 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.
>>>
>>
>> If i correctly remember we agreed to solve the routing issu in a generic 
>> approach, not the signaling one.
> 
> 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
> 
>> 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
>>>>
>>>>
>>>>
>>>
> 
> 
> 
> 
> 
>