[CCAMP] R: Closing G.709 open issues

["BELOTTI, SERGIO (SERGIO)" <[e-mail]>]

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.

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. 

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