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

[Lou Berger <[e-mail]>]

Fatai,
	
That's a great start for the WG.  Thank you.

To answer your implied question as to why my request for the full list.
 My feeling is that there have been too many "surprises" on the 709
documents in areas that I thought were either obvious (but from the IETF
& GMPLS context, not ITU-T or G.709 perspectives) or resolved by past
discussions.  At this point, as co-chair and Document shepherd, I want
to ensure that any open point on the documents are unambiguously closed
and that past discussions (i.e., points of consensus) are 100% captured,
so that we can smoothly move through the planned second LC and
publication request.

To that end, in my previous message I asked two questions about points
where it seems you are proposing moving away from what has been
previously been discussed & agreed to by the WG.  Can you answer the
following:

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

Much thanks,
Lou

On 5/17/2013 3:58 AM, Fatai Zhang wrote:> Hi Lou,
>
> I thought it should be sufficient for me to identify the **updated** and
> **new** G-PIDs in this draft (I compared [G.709-2003] and [G.709-2012],
> and checked RFC4328), but I would be happy to provide a full list for
> your request.
>
> Please see the list below, and the new payload types introduced by
> [G.709-2012] (and the corresponding new G-PIDs defined in this draft)
> are in the light blue cells.
>
> Please check if there is anything missed or wrong. Note that GPIDs like
> 32,47,49-52 have been updated in this draft.
>
> Note that we as authors welcome any contributors for their contribution.
>
> For you convenience, I also attached the word document.
>
>
> *G-PIDs vs **Payload types defined in Table 15-8 of G.709*
>
> G-PID
> 	
> LSP Encoding
> 	
> Payload Type in Hex codedefined in G.709
> 	
> Note
> 	
> Interpretationfrom G.709
> None
> 	
>
> 	
> 0x01
> 	
> Not needed
> 	
> Experimental mapping (Note 3)
> 49
> 	
> G.709 ODUk, G.709 OCh
> 	
> 0x02
> 	
> 1)G-PID defined in RFC4328;
> 2) Updated in this draft.
> 	
> Asynchronous CBR mapping, see clause 17.2
> 50
> 	
> G.709 ODUk
> 	
> 0x03
> 	
> ditto
> 	
> Bit synchronous CBR mapping, see clause 17.2
> 32
> 	
> SDH, G.709 ODUk
> 	
> 0x04
> 	
> ditto
> 	
> ATM mapping, see clause 17.3
> 54
> 	
> G.709 ODUk (and SDH)
>
> 	
> 0x05
> 	
> G-PIDs defined in RFC4328 with two kinds of GFPs (Ethernet MAC (framed
GFP)
>
> 	
> GFP mapping, see clause 17.4
> None
> 	
>
> 	
> 0x06
> 	
> Not needed and Not defined in RFC4328
> 	
> Virtual Concatenated signal, see clause 18 (Note 5)
> 61(TBA)
> 	
> G.709 ODUk (k=0,3,4)
> 	
> 0x07
> 	
> Is being defined in this draft (new payload type defined in [G.709-2012])
> 	
> PCS codeword transparent Ethernet mapping:
> ·      1000BASE-X into OPU0, see clauses 17.7.1 and 17.7.1.1
> ·      40GBASE-R into OPU3, see clauses 17.7.4 and 17.7.4.1
> ·      100GBASE-R into OPU4, see clauses 17.7.5 and 17.7.5.1
> 62(TBA)
> 	
> G.709 ODUk (k=2e)
> 	
> 0x08
> 	
> ditto
> 	
> FC-1200 into OPU2e mapping, see clause 17.8.2
> 63(TBA)
> 	
> G.709 ODUk (k=2)
> 	
> 0x09
> 	
> ditto
> 	
> GFP mapping into Extended OPU2 payload, see clause 17.4.1 (Note 6)
> 64(TBA)
> 	
> G.709 ODUk (k=0)
> 	
> 0x0A
> 	
> ditto
> 	
> STM-1 mapping into OPU0, see clause 17.7.1
> 65(TBA)
> 	
> G.709 ODUk (k=0)
> 	
> 0x0B
> 	
> ditto
> 	
> STM-4 mapping into OPU0, see clause 17.7.1
> 66(TBA)
> 	
> G.709 ODUk (k=0)
> 	
> 0x0C
> 	
> ditto
> 	
> FC-100 mapping into OPU0, see clause 17.7.1
> 67(TBA)
> 	
> G.709 ODUk (k=1)
> 	
> 0x0D
> 	
> ditto
> 	
> FC-200 mapping into OPU1, see clause 17.7.2
> 68(TBA)
> 	
> G.709 ODUflex
> 	
> 0x0E
> 	
> ditto
> 	
> FC-400 mapping into OPUflex, see clause 17.9
> 69(TBA)
> 	
> G.709 ODUflex
> 	
> 0x0F
> 	
> ditto
> 	
> FC-800 mapping into OPUflex, see clause 17.9
> 51
> 	
> G.709 ODUk
> 	
> 0x10
> 	
> 1)G-PID defined in RFC4328;
> 2) Updated in this draft.
> 	
> Bit stream with octet timing mapping, see clause 17.6.1
> 52
> 	
> G.709 ODUk
> 	
> 0x11
> 	
> ditto
> 	
> Bit stream without octet timing mapping, see clause 17.6.2
> 70(TBA)
> 	
> G.709 ODUflex
> 	
> 0x12
> 	
> Is being defined in this draft (new payload type defined in [G.709-2012])
> 	
> IB SDR  mapping into OPUflex, see 17.9
> 71(TBA)
> 	
> G.709 ODUflex
> 	
> 0x13
> 	
> ditto
> 	
> IB DDR mapping into OPUflex, see 17.9
> 72(TBA)
> 	
> G.709 ODUflex
> 	
> 0x14
> 	
> ditto
> 	
> IB QDR mapping into OPUflex, see 17.9
> 73(TBA)
> 	
> G.709 ODUk (k=0)
> 	
> 0x15
> 	
> ditto
> 	
> SDI  mapping into OPU0, see 17.7.1
> 74(TBA)
> 	
> G.709 ODUk (k=1)
> 	
> 0x16
> 	
> ditto
> 	
> (1.485/1.001) Gbit/s SDI mapping into OPU1, see 17.7.2
> 75(TBA)
> 	
> G.709 ODUk (k=1)
> 	
> 0x17
> 	
> ditto
> 	
> 1.485 Gbit/s SDI mapping into OPU1, see 17.7.2
> 76(TBA)
> 	
> G.709 ODUflex
> 	
> 0x18
> 	
> ditto
> 	
> (2.970/1.001) Gbit/s SDI mapping into OPUflex, see 17.9
> 77(TBA)
> 	
> G.709 ODUflex
> 	
> 0x19
> 	
> ditto
> 	
> 2.970 Gbit/s SDI mapping into OPUflex, see 17.9
> 78(TBA)
> 	
> G.709 ODUk (k=0)
> 	
> 0x1A
> 	
> ditto
> 	
> SBCON/ESCON mapping into OPU0, see 17.7.1
> 79(TBA)
> 	
> G.709 ODUk (k=0)
> 	
> 0x1B
> 	
> ditto
> 	
> DVB_ASI mapping into OPU0, see 17.7.1
> 47
> 	
> G.709 ODUk
> 	
> 0x20
> 	
> 1) G-PIDs defined in RFC4328.
> 2) Updated in this draft.
> 	
> ODU multiplex structure supporting ODTUjk only, see clause 19 (AMP only)
> 59/60
> 	
> G.709 ODUk
> 	
> 0x21
> 	
> 1)Are being defined in this draft (new payload type defined in
> [G.709-2012]);
> 2) 59 for G.709 ODU-1.25G; 60 for G.709 ODU-any
> 	
> ODU multiplex structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see
> clause 19 (GMP capable) (Note 7)
> None
> 	
>
> 	
> 55
> 	
> Not needed
> 	
> Not available (Note 2)
> None
> 	
>
> 	
> 66
> 	
> Not needed
> 	
> Not available (Note 2)
> None
> 	
>
> 	
> 80-8F
> 	
> Not needed
> 	
> Reserved codes for proprietary use (Note 4)
> None
> 	
>
> 	
> FD
> 	
> Not needed
> 	
> NULL test signal mapping, see clause 17.5.1
> None
> 	
>
> 	
> FE
> 	
> Not needed
> 	
> PRBS test signal mapping, see clause 17.5.2
> None
> 	
>
> 	
> FF
> 	
> Not needed
> 	
> Not available (Note 2)
>
> 	
>
> 	
>
> 	
>
> 	
>
>
>
>
>
>
> Best Regards
>
> Fatai
>
>
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Wednesday, May 15, 2013 10:58 PM
> To: BELOTTI, SERGIO (SERGIO); Fatai Zhang
> Cc: Daniele Ceccarelli; CCAMP;
> [e-mail]
> Subject: Re: R: Closing G.709 open issues
>
> 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
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>>
>>
>>
>>
>