Re: [CCAMP] Closing G.709 open issues

[Lou Berger <[e-mail]>]

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