Re: [CCAMP] R: R: R: Closing Issue #49 (Was: Re: R: Closing G.709 open issues)

[Lou Berger <[e-mail]>]

>> What *specific* changes/additions do you think are needed?
>>
> SB> NO, the changes you have done capture my suggestion.

Excellent.  This comment is now addressed/closed.

Authors,

Please update the draft based on the table included below, as well as
the issue 48 discussion.  If there are other corrections/additions, they
can be picked up as they come in, or as part of the 2nd LC.

Lou

On 5/28/2013 12:12 PM, BELOTTI, SERGIO (SERGIO) wrote:
> Lou,
> 
> Obviously opinion are opinion since anyone can see things in a different way: I thought to do a favour to include suggestion in the word file used during the discussion by Fatai...
> 
> Anyway below my notes.
> 
> 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: martedì 28 maggio 2013 17.49
> A: BELOTTI, SERGIO (SERGIO)
> Cc: CCAMP; [e-mail]; Fatai Zhang; Beller, Dieter (Dieter)
> Oggetto: Re: R: R: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)
> 
> Sergio,
> 	See below.
> 
> Also, can you just put your comments/discussion points in mail rather
> than a word file?  I don't think the use of word is providing any value
> in this context.
> 
> On 5/28/2013 11:02 AM, BELOTTI, SERGIO (SERGIO) wrote:
>> Hi Lou,
>>
>> See below for my notes .
>> I attached the Fatai's doc for GPID mapping with possible suggested addon.
>>
>> Thanks
>>
>> 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: venerdì 24 maggio 2013 18.33
>> A: BELOTTI, SERGIO (SERGIO)
>> Cc: CCAMP; [e-mail]; Fatai Zhang
>> Oggetto: Re: R: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)
>>
>> Sergio,
>>
>>
>> On 5/24/2013 11:54 AM, BELOTTI, SERGIO (SERGIO) wrote:
>>> Hi,
>>>
>>> Please take care anyway this solution does not consider two cases:
>>>
>>> G.7041 and G.709, defines respectively:
>>>
>>> 10GbE --> GFP-F (G.7041, Table 6-3: UPI=0x13  [ Frame-mapped 64B/66B encoded
>>> Ethernet, including the Ethernet frame preamble ])
>>
>> Cool, yet another way to encode Ethernet over GFP. (Pointing to the
>> G.7041 UPI was very helpful, the draft will need to capture that!)  What
>> PT is used for this?  Are there other client types missing/that you
>> think are missing?
>>
>> SB> In G.7041 Table 6-3 - User payload identifiers for GFP client frames  define the UPI values.
>>  UPI is setup according to the transported signal type.
>> Here we can see there is another form of Ethernet mapping via GFP and  ODU2 signals can carry  diverse payloads including diverse GFP-F mapped Ethernet.
>> I think the best we can do would be to define GPID values for all possible/meaningful combinations of PT/UPI values where GFP is used to encapsulate the client signal.
>>
>> What I have indicated here are just two possible addon: one is already considered in the file provided by Fatai , the other is the one form G.7041.
>> Attached the doc from Fatai, updated (in yellow) with the new GFP Ethernet mapping possibility.
> 
> Unless I misread it, you didn't propose any new G-PIDs.
> 
> SB> In fact you misread
> 
>>
>>
>> My suggestion would be to define GPID values for all
>> possible/meaningful combinations of PT/UPI values where GFP is used
>> to encapsulate the client signal.
>>
> 
> If you want to define additional types, please propose them!  If there
> are no specifics, there's nothing for the WG to discuss/agree to.
> 
> SB> I've attached the file for that as clearly explained.
> 
>>>
>>> 10GbE--> extended OPU2/ODU2 (G.709, Table 15-8: PT=0x09 [ GFP mapping into Extended
>>> OPU2 payload, see clause 17.4.1 ])
>>
>> Is this a different case? If yes, how so? (Do you have a data plane
>> reference?)
>>
>> SB> For ODU2 in OTN there is two possible PT options for 10GbE and are
>>  PT= 0x05 (ODU2) | PT = 0x09 (extended ODU2)
> 
> Okay, sounds like a new G-PID type (TBA12 below). So here's the updated
> table as I understand it:
> 
>     G.709
>    Payload
>     Type   G-PID   Type/Comment    LSP Encoding
>     ====   =====   ==============  ===================
>     0x01           No standard value
>     0x02    49     CBRa            G.709 ODUk
>     0x03    50     CBRb            G.709 ODUk
>     0x04    32     ATM             G.709 ODUk
>     0x05    TBA1   Framed GFP      G.709 ODUk
>             54     Ethernet MAC    G.709 ODUk
>                    (framed GFP)
>             TBA12  64B/66B GFP-F   G.709 ODUk (k=2)
>                    Ethernet
>     0x06    ???    Is any valued needed?
>     0x07    55     Ethernet PHY    G.709 ODUk (k=0)
>                    (transparent    G.709 ODUk (k=3)
>                    GFP)            G.709 ODUk (k=4)
>     0x08    58     Fiber Channel   G.709 ODUk (k=2e)
>     0x09    TBA1   Framed GFP      G.709 ODUk (k=2e)
>             TBA12  64B/66B GFP-F   G.709 ODUk (k=2)
>                    Ethernet
>     0x0A    TBA2   STM-1           G.709 ODUk (k=0)
>     0x0B    TBA3   STM-4           G.709 ODUk (k=0)
>     0x0C    58     Fiber Channel   G.709 ODUk (k=0)
>     0x0D    58     Fiber Channel   G.709 ODUk (k=1)
>     0x0E    58     Fiber Channel   G.709 ODUflex
>     0x0F    58     Fiber Channel   G.709 ODUflex
>     0x10    51     BSOT            G.709 ODUk
>     0x11    52     BSNT            G.709 ODUk
>     0x12    TBA4   InfiniBand      G.709 ODUflex
>     0x13    TBA4   InfiniBand      G.709 ODUflex
>     0x14    TBA4   InfiniBand      G.709 ODUflex
>     0x15    TBA5   Serial Digital  G.709 ODUk (k=0)
>                    Interface
>     0x16    TBA6   Serial Digital  G.709 ODUk (k=1)
>                    Interface/1.001
>     0x17    TBA5   Serial Digital  G.709 ODUk (k=1)
>                    Interface
>     0x18    TBA6   Serial Digital  G.709 ODUflex
>                    Interface/1.001
>     0x19    TBA5   Serial Digital  G.709 ODUflex
>                    Interface
>     0x1A    56     SBCON/ESCON     G.709 ODUk (k=0)
>                    (IANA to update Type field)
>     0x1B    TBA7   DVB_ASI         G.709 ODUk (k=0)
>     0x1C    58     Fiber Channel   G.709 ODUk
>     0x20    47     G.709 ODU-2.5G  G.709 ODUk
>                                      (k=2,3)
>                    (IANA to update Type field)
>             TBA8   G.709 ODU-1.25G G.709 ODUk
>                                      (k=1,2,3)
>     0x21    TBA8   G.709 ODU-1.25G G.709 ODUk
>                                      (k=2,3,4)
>             TBA9   G.709 ODU-Any   G.709 ODUk
>                                    (k=2,3)
>     0x55           No standard value
>     0x66           No standard value
>     0x80-0x8F      No standard value
>     0xFD    TBA10  Null Test       G.709 ODUk
>     0xFE    TBA11  Random Test     G.709 ODUk
>     0xFF           No standard value
> 
> What *specific* changes/additions do you think are needed? (Please add
> to this table and NOT the word file, once we have agreement on e-mail
> the result can be directly inserted into the draft.)
> 
> SB> NO, the changes you have done capture my suggestion.
> 
> Lou
> 
>>
>> Thanks,
>> Lou
>>
>>>
>>> Please not that this is not the mapping using UPI=0x01 and PT=0x05
>>>
>>> Best Regards
>>>
>>> Sergio
>>>
>>> Belotti Sergio-  System Architect
>>> ALCATE-LUCENT  Optics Division
>>> via Trento 30 Vimercate (MB) - Italy
>>> phone [phone]
>>> -----Messaggio originale-----
>>> Da: [e-mail] [mailto:[e-mail]] Per conto di Lou Berger
>>> Inviato: venerdì 24 maggio 2013 15.15
>>> A: Fatai Zhang
>>> Cc: CCAMP; [e-mail]
>>> Oggetto: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)
>>>
>>> Fatai,
>>>
>>> Just to be clear, the following covers your correction:
>>>
>>>     G.709
>>>    Payload
>>>     Type   G-PID   Type/Comment    LSP Encoding
>>>     ====   =====   ==============  ===================
>>>     0x05    TBA1   Framed GFP      G.709 ODUk
>>>             54     Ethernet MAC    G.709 ODUk
>>>                    (framed GFP)
>>>
>>> Right?
>>>
>>> Thanks,
>>> Lou
>>>
>>> On 5/23/2013 9:01 PM, Fatai Zhang wrote:
>>>> Hi Lou,
>>>>
>>>> Fine, thanks for your explanation.
>>>>
>>>> As I said, I will update the signaling draft based on your proposal if there are no further comments.
>>>>
>>>>
>>>>
>>>> Best Regards
>>>>
>>>> Fatai
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:[e-mail]] 
>>>> Sent: Friday, May 24, 2013 12:15 AM
>>>> To: Fatai Zhang
>>>> Cc: CCAMP; [e-mail]
>>>> Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)
>>>>
>>>> Fatai,
>>>> 	Do we really need to reopen debate on a topic the WG discussed and
>>>> closed last summer?  (i.e., to handle G.709 client adaptation just as we
>>>> do for every other technology.)
>>>>
>>>> I do agree that some new G-PID assignments were missed in the draft that
>>>> went to LC, but filling in the list doesn't automatically mean that the
>>>> WG needs to reopen debate on adaptation approaches.
>>>>
>>>> Assuming we don't need to reopen the pre-LC debate from last summer, and
>>>> with respect to the list I sent out, I do agree the WG needs to:
>>>>
>>>> A) Ensure that the list doesn't have unneeded new G-PIDs (i.e., reuses
>>>> the same/existing G-PIDs wherever possible.)
>>>>
>>>> B) Identifies the "right" G-PID per payload type, and doesn't have any
>>>> other technical errors
>>>>
>>>> C) Doesn't conflict with past WG decisions/discussions.
>>>>
>>>> >From your mails I see the following comment on (A):
>>>>
>>>>> For 0x05, why you think that RFC4328 does not cover it (ie., G-PID=54)?
>>>>
>>>> G-PID 54, per IANA, is currently defined as "Ethernet MAC (framed GFP)".
>>>>  Per G.709, PT=0x05 maps to "GFP mapping, see clause 17.4" and looking
>>>> at 17.4 there is no restriction on what is carried in GFP frames.  So it
>>>> seems that PT=0x05 can't be limited to just "Ethernet MAC (framed GFP)".
>>>>
>>>> Are you suggesting changing the type description of G-PID 54 to just
>>>> "Framed GFP", or including G-PID 54 as an additional possibility for
>>>> PT=0x05?
>>>>
>>>> The latter seems to be a valid addition/correction.  The former may be
>>>> problematic for existing implementations, so we'll need to discuss more
>>>> broadly if that's the direction you want to head.
>>>>
>>>> All/ (WG),
>>>>
>>>> Again, please speak up if you think the above is not aligned with prior
>>>> consensus or if you have an issue with any of the above.
>>>>
>>>> Lou
>>>>
>>>> On 5/22/2013 10:35 PM, Fatai Zhang wrote:
>>>>> Hi Lou,
>>>>>
>>>>>  
>>>>>
>>>>> I incorporated your proposal into my table to facilitate the readers.
>>>>>
>>>>>  
>>>>>
>>>>> I think you still insist on reusing some existing G-PIDs like 58, 56.
>>>>>  For 0x04, why you think that RFC4328 does not cover it (ie., G-PID=54)?
>>>>>
>>>>>  
>>>>>
>>>>> Technically, I am not convince by your proposal, but I would like to
>>>>> reserve my opinion for your same motivation (ie., to conclude the
>>>>> discussion as soon as possible).
>>>>>
>>>>>  
>>>>>
>>>>> Any opinions on Lou's proposal from the WG? I will update the signaling
>>>>> draft based on Lou's proposal if there is no comment on Lou's proposal.
>>>>>
>>>>>  
>>>>>
>>>>> Note that all the new G-PID values will be re-ordered with TBA.
>>>>>
>>>>>  
>>>>>
>>>>> *G-PIDs vs **Payload types defined in Table 15-8 of G.709*
>>>>>
>>>>>  
>>>>>
>>>>> Payload Type in Hex codedefined in G.709
>>>>>
>>>>> 	
>>>>>
>>>>> G-PID
>>>>>
>>>>> 	
>>>>>
>>>>> LSP Encoding
>>>>>
>>>>> 	
>>>>>
>>>>> Note
>>>>>
>>>>> 	
>>>>>
>>>>> Interpretationfrom G.709
>>>>>
>>>>> 0x01
>>>>>
>>>>> 	
>>>>>
>>>>> None
>>>>>
>>>>> 	
>>>>>
>>>>>  
>>>>>
>>>>> 	
>>>>>
>>>>> Not needed
>>>>>
>>>>> 	
>>>>>
>>>>> Experimental mapping (Note 3)
>>>>>
>>>>> 0x02
>>>>>
>>>>> 	
>>>>>
>>>>> 49
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUk, G.709 OCh
>>>>>
>>>>> 	
>>>>>
>>>>> 1)G-PID defined in RFC4328;
>>>>>
>>>>> 2) Updated in this draft.
>>>>>
>>>>> 	
>>>>>
>>>>> Asynchronous CBR mapping, see clause 17.2
>>>>>
>>>>> 0x03
>>>>>
>>>>> 	
>>>>>
>>>>> 50
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUk
>>>>>
>>>>> 	
>>>>>
>>>>> ditto
>>>>>
>>>>> 	
>>>>>
>>>>> Bit synchronous CBR mapping, see clause 17.2
>>>>>
>>>>> 0x04
>>>>>
>>>>> 	
>>>>>
>>>>> 32
>>>>>
>>>>> 	
>>>>>
>>>>> SDH, G.709 ODUk
>>>>>
>>>>> 	
>>>>>
>>>>> ditto
>>>>>
>>>>> 	
>>>>>
>>>>> ATM mapping, see clause 17.3
>>>>>
>>>>> 0x05
>>>>>
>>>>> 	
>>>>>
>>>>> 54
>>>>>
>>>>> or
>>>>>
>>>>> TBA (Suggested by Lou)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUk (and SDH)
>>>>>
>>>>>  
>>>>>
>>>>> 	
>>>>>
>>>>> G-PIDs defined in RFC4328 for framed GFP
>>>>>
>>>>>  
>>>>>
>>>>> 	
>>>>>
>>>>> GFP mapping, see clause 17.4
>>>>>
>>>>> 0x06
>>>>>
>>>>> 	
>>>>>
>>>>> None
>>>>>
>>>>> 	
>>>>>
>>>>>  
>>>>>
>>>>> 	
>>>>>
>>>>> Not needed and Not defined in RFC4328
>>>>>
>>>>> 	
>>>>>
>>>>> Virtual Concatenated signal, see clause 18 (Note 5)
>>>>>
>>>>> 0x07
>>>>>
>>>>> 	
>>>>>
>>>>> 61(TBA)
>>>>>
>>>>> Or55(Suggested by Lou)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUk (k=0,3,4)
>>>>>
>>>>> 	
>>>>>
>>>>> 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
>>>>>
>>>>> 0x08
>>>>>
>>>>> 	
>>>>>
>>>>> 62(TBA)
>>>>>
>>>>> Or58(Suggested by Lou)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUk (k=2e)
>>>>>
>>>>> 	
>>>>>
>>>>> ditto
>>>>>
>>>>> 	
>>>>>
>>>>> FC-1200 into OPU2e mapping, see clause 17.8.2
>>>>>
>>>>> 0x09
>>>>>
>>>>> 	
>>>>>
>>>>> 63(TBA)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUk (k=2)
>>>>>
>>>>> 	
>>>>>
>>>>> ditto
>>>>>
>>>>> 	
>>>>>
>>>>> GFP mapping into Extended OPU2 payload, see clause 17.4.1 (Note 6)
>>>>>
>>>>> 0x0A
>>>>>
>>>>> 	
>>>>>
>>>>> 64(TBA)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUk (k=0)
>>>>>
>>>>> 	
>>>>>
>>>>> ditto
>>>>>
>>>>> 	
>>>>>
>>>>> STM-1 mapping into OPU0, see clause 17.7.1
>>>>>
>>>>> 0x0B
>>>>>
>>>>> 	
>>>>>
>>>>> 65(TBA)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUk (k=0)
>>>>>
>>>>> 	
>>>>>
>>>>> ditto
>>>>>
>>>>> 	
>>>>>
>>>>> STM-4 mapping into OPU0, see clause 17.7.1
>>>>>
>>>>> 0x0C
>>>>>
>>>>> 	
>>>>>
>>>>> 66(TBA)
>>>>>
>>>>> Or58(Suggested by Lou)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUk (k=0)
>>>>>
>>>>> 	
>>>>>
>>>>> ditto
>>>>>
>>>>> 	
>>>>>
>>>>> FC-100 mapping into OPU0, see clause 17.7.1
>>>>>
>>>>> 0x0D
>>>>>
>>>>> 	
>>>>>
>>>>> 67(TBA)
>>>>>
>>>>> Or58(Suggested by Lou)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUk (k=1)
>>>>>
>>>>> 	
>>>>>
>>>>> ditto
>>>>>
>>>>> 	
>>>>>
>>>>> FC-200 mapping into OPU1, see clause 17.7.2
>>>>>
>>>>> 0x0E
>>>>>
>>>>> 	
>>>>>
>>>>> 68(TBA)
>>>>>
>>>>> Or58(Suggested by Lou)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUflex
>>>>>
>>>>> 	
>>>>>
>>>>> ditto
>>>>>
>>>>> 	
>>>>>
>>>>> FC-400 mapping into OPUflex, see clause 17.9
>>>>>
>>>>> 0x0F
>>>>>
>>>>> 	
>>>>>
>>>>> 69(TBA)
>>>>>
>>>>> Or58(Suggested by Lou)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUflex
>>>>>
>>>>> 	
>>>>>
>>>>> ditto
>>>>>
>>>>> 	
>>>>>
>>>>> FC-800 mapping into OPUflex, see clause 17.9
>>>>>
>>>>> 0x10
>>>>>
>>>>> 	
>>>>>
>>>>> 51
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUk
>>>>>
>>>>> 	
>>>>>
>>>>> 1)G-PID defined in RFC4328;
>>>>>
>>>>> 2) Updated in this draft.
>>>>>
>>>>> 	
>>>>>
>>>>> Bit stream with octet timing mapping, see clause 17.6.1
>>>>>
>>>>> 0x11
>>>>>
>>>>> 	
>>>>>
>>>>> 52
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUk
>>>>>
>>>>> 	
>>>>>
>>>>> ditto
>>>>>
>>>>> 	
>>>>>
>>>>> Bit stream without octet timing mapping, see clause 17.6.2
>>>>>
>>>>> 0x12
>>>>>
>>>>> 	
>>>>>
>>>>> 70(TBA)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUflex
>>>>>
>>>>> 	
>>>>>
>>>>> Is being defined in this draft (new payload type defined in [G.709-2012])
>>>>>
>>>>> 	
>>>>>
>>>>> IB SDR  mapping into OPUflex, see 17.9
>>>>>
>>>>> 0x13
>>>>>
>>>>> 	
>>>>>
>>>>> 71(TBA)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUflex
>>>>>
>>>>> 	
>>>>>
>>>>> ditto
>>>>>
>>>>> 	
>>>>>
>>>>> IB DDR mapping into OPUflex, see 17.9
>>>>>
>>>>> 0x14
>>>>>
>>>>> 	
>>>>>
>>>>> 72(TBA)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUflex
>>>>>
>>>>> 	
>>>>>
>>>>> ditto
>>>>>
>>>>> 	
>>>>>
>>>>> IB QDR mapping into OPUflex, see 17.9
>>>>>
>>>>> 0x15
>>>>>
>>>>> 	
>>>>>
>>>>> 73(TBA)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUk (k=0)
>>>>>
>>>>> 	
>>>>>
>>>>> ditto
>>>>>
>>>>> 	
>>>>>
>>>>> SDI  mapping into OPU0, see 17.7.1
>>>>>
>>>>> 0x16
>>>>>
>>>>> 	
>>>>>
>>>>> 74(TBA)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUk (k=1)
>>>>>
>>>>> 	
>>>>>
>>>>> ditto
>>>>>
>>>>> 	
>>>>>
>>>>> (1.485/1.001) Gbit/s SDI mapping into OPU1, see 17.7.2
>>>>>
>>>>> 0x17
>>>>>
>>>>> 	
>>>>>
>>>>> 75(TBA)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUk (k=1)
>>>>>
>>>>> 	
>>>>>
>>>>> ditto
>>>>>
>>>>> 	
>>>>>
>>>>> 1.485 Gbit/s SDI mapping into OPU1, see 17.7.2
>>>>>
>>>>> 0x18
>>>>>
>>>>> 	
>>>>>
>>>>> 76(TBA)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUflex
>>>>>
>>>>> 	
>>>>>
>>>>> ditto
>>>>>
>>>>> 	
>>>>>
>>>>> (2.970/1.001) Gbit/s SDI mapping into OPUflex, see 17.9
>>>>>
>>>>> 0x19
>>>>>
>>>>> 	
>>>>>
>>>>> 77(TBA)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUflex
>>>>>
>>>>> 	
>>>>>
>>>>> ditto
>>>>>
>>>>> 	
>>>>>
>>>>> 2.970 Gbit/s SDI mapping into OPUflex, see 17.9
>>>>>
>>>>> 0x1A
>>>>>
>>>>> 	
>>>>>
>>>>> 78(TBA)
>>>>>
>>>>> Or56(Suggested by Lou)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUk (k=0)
>>>>>
>>>>> 	
>>>>>
>>>>> ditto
>>>>>
>>>>> 	
>>>>>
>>>>> SBCON/ESCON mapping into OPU0, see 17.7.1
>>>>>
>>>>> 0x1B
>>>>>
>>>>> 	
>>>>>
>>>>> 79(TBA)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUk (k=0)
>>>>>
>>>>> 	
>>>>>
>>>>> ditto
>>>>>
>>>>> 	
>>>>>
>>>>> DVB_ASI mapping into OPU0, see 17.7.1
>>>>>
>>>>> 0x20
>>>>>
>>>>> 	
>>>>>
>>>>> 47
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUk
>>>>>
>>>>> 	
>>>>>
>>>>> 1) G-PIDs defined in RFC4328.
>>>>>
>>>>> 2) Updated in this draft.
>>>>>
>>>>> 	
>>>>>
>>>>> ODU multiplex structure supporting ODTUjk only, see clause 19 (AMP only)
>>>>>
>>>>> 0x21
>>>>>
>>>>> 	
>>>>>
>>>>> 59/60(TBA)
>>>>>
>>>>> 	
>>>>>
>>>>> G.709 ODUk
>>>>>
>>>>> 	
>>>>>
>>>>> 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)
>>>>>
>>>>> 55
>>>>>
>>>>> 	
>>>>>
>>>>> None
>>>>>
>>>>> 	
>>>>>
>>>>>  
>>>>>
>>>>> 	
>>>>>
>>>>> Not needed
>>>>>
>>>>> 	
>>>>>
>>>>> Not available (Note 2)
>>>>>
>>>>> 66
>>>>>
>>>>> 	
>>>>>
>>>>> None
>>>>>
>>>>> 	
>>>>>
>>>>>  
>>>>>
>>>>> 	
>>>>>
>>>>> Not needed
>>>>>
>>>>> 	
>>>>>
>>>>> Not available (Note 2)
>>>>>
>>>>> 80-8F
>>>>>
>>>>> 	
>>>>>
>>>>> None
>>>>>
>>>>> 	
>>>>>
>>>>>  
>>>>>
>>>>> 	
>>>>>
>>>>> Not needed
>>>>>
>>>>> 	
>>>>>
>>>>> Reserved codes for proprietary use (Note 4)
>>>>>
>>>>> FD
>>>>>
>>>>> 	
>>>>>
>>>>> None
>>>>>
>>>>> OrTBA(Suggested by Lou)
>>>>>
>>>>> 	
>>>>>
>>>>>  
>>>>>
>>>>> 	
>>>>>
>>>>> Not needed
>>>>>
>>>>> 	
>>>>>
>>>>> NULL test signal mapping, see clause 17.5.1
>>>>>
>>>>> FE
>>>>>
>>>>> 	
>>>>>
>>>>> None
>>>>>
>>>>> OrTBA(Suggested by Lou)
>>>>>
>>>>> 	
>>>>>
>>>>>  
>>>>>
>>>>> 	
>>>>>
>>>>> Not needed
>>>>>
>>>>> 	
>>>>>
>>>>> PRBS test signal mapping, see clause 17.5.2
>>>>>
>>>>> FF
>>>>>
>>>>> 	
>>>>>
>>>>> None
>>>>>
>>>>> 	
>>>>>
>>>>>  
>>>>>
>>>>> 	
>>>>>
>>>>> Not needed
>>>>>
>>>>> 	
>>>>>
>>>>> Not available (Note 2)
>>>>>
>>>>>  
>>>>>
>>>>> 	
>>>>>
>>>>>  
>>>>>
>>>>> 	
>>>>>
>>>>>  
>>>>>
>>>>> 	
>>>>>
>>>>>  
>>>>>
>>>>> 	
>>>>>
>>>>>  
>>>>>
>>>>>  
>>>>>
>>>>>  
>>>>>
>>>>>  
>>>>>
>>>>>  
>>>>>
>>>>> Best Regards
>>>>>
>>>>>  
>>>>>
>>>>> Fatai
>>>>>
>>>>>  
>>>>>
>>>>>  
>>>>>
>>>>> -----Original Message-----
>>>>> From: [e-mail] [mailto:[e-mail]] On Behalf
>>>>> Of Lou Berger
>>>>> Sent: Tuesday, May 21, 2013 9:17 PM
>>>>> To: CCAMP
>>>>> Cc: [e-mail]
>>>>> Subject: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)
>>>>>
>>>>>  
>>>>>
>>>>> All,
>>>>>
>>>>>  
>>>>>
>>>>> In the interest of moving this discussion quickly to closure, I spent
>>>>>
>>>>> some time trying to come up with the full list of G.709 PT to G-PID
>>>>>
>>>>> mappings.  In coming up with this list I tried to be consistent with
>>>>>
>>>>> the last consensus point that I can identify on this topic (the
>>>>>
>>>>> previously referenced July 2012 thread & presentation), which included:
>>>>>
>>>>>  
>>>>>
>>>>> A) Defining new G-PIDs for client types not identified by an assigned
>>>>>
>>>>> G-PID (per
>>>>>
>>>>> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml)
>>>>>
>>>>>  
>>>>>
>>>>> B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a
>>>>>
>>>>> G.709 payload type, and define new G-PIDs when reuse not possible.
>>>>>
>>>>>  
>>>>>
>>>>> C) No G-PID value for unused, reserved, or proprietary 709 Payload Type.
>>>>>
>>>>>  
>>>>>
>>>>> Here's what I've come up with:
>>>>>
>>>>>  
>>>>>
>>>>>     G.709
>>>>>
>>>>>    Payload
>>>>>
>>>>>     Type   G-PID   Type/Comment    LSP Encoding
>>>>>
>>>>>     ====   =====   ==============  ===================
>>>>>
>>>>>     0x01           No standard value
>>>>>
>>>>>     0x02    49     CBRa            G.709 ODUk
>>>>>
>>>>>     0x03    50     CBRb            G.709 ODUk
>>>>>
>>>>>     0x04    32     ATM             G.709 ODUk
>>>>>
>>>>>     0x05    TBA1   Framed GFP      G.709 ODUk
>>>>>
>>>>>     0x06    ???    Is any valued needed?
>>>>>
>>>>>     0x07    55     Ethernet PHY    G.709 ODUk (k=0)
>>>>>
>>>>>                    (transparent    G.709 ODUk (k=3)
>>>>>
>>>>>                    GFP)            G.709 ODUk (k=4)
>>>>>
>>>>>     0x08    58     Fiber Channel   G.709 ODUk (k=2e)
>>>>>
>>>>>     0x09    TBA1   Framed GFP      G.709 ODUk (k=2e)
>>>>>
>>>>>     0x0A    TBA2   STM-1           G.709 ODUk (k=0)
>>>>>
>>>>>     0x0B    TBA3   STM-4           G.709 ODUk (k=0)
>>>>>
>>>>>     0x0C    58     Fiber Channel   G.709 ODUk (k=0)
>>>>>
>>>>>     0x0D    58     Fiber Channel   G.709 ODUk (k=1)
>>>>>
>>>>>     0x0E    58     Fiber Channel   G.709 ODUflex
>>>>>
>>>>>     0x0F    58     Fiber Channel   G.709 ODUflex
>>>>>
>>>>>     0x10    51     BSOT            G.709 ODUk
>>>>>
>>>>>     0x11    52     BSNT            G.709 ODUk
>>>>>
>>>>>     0x12    TBA4   InfiniBand      G.709 ODUflex
>>>>>
>>>>>     0x13    TBA4   InfiniBand      G.709 ODUflex
>>>>>
>>>>>     0x14    TBA4   InfiniBand      G.709 ODUflex
>>>>>
>>>>>     0x15    TBA5   Serial Digital  G.709 ODUk (k=0)
>>>>>
>>>>>                    Interface
>>>>>
>>>>>     0x16    TBA6   Serial Digital  G.709 ODUk (k=1)
>>>>>
>>>>>                    Interface/1.001
>>>>>
>>>>>     0x17    TBA5   Serial Digital  G.709 ODUk (k=1)
>>>>>
>>>>>                    Interface
>>>>>
>>>>>     0x18    TBA6   Serial Digital  G.709 ODUflex
>>>>>
>>>>>                    Interface/1.001
>>>>>
>>>>>     0x19    TBA5   Serial Digital  G.709 ODUflex
>>>>>
>>>>>                    Interface
>>>>>
>>>>>     0x1A    56     SBCON/ESCON     G.709 ODUk (k=0)
>>>>>
>>>>>                    (IANA to update Type field)
>>>>>
>>>>>     0x1B    TBA7   DVB_ASI         G.709 ODUk (k=0)
>>>>>
>>>>>     0x1C    58     Fiber Channel   G.709 ODUk
>>>>>
>>>>>     0x20    47     G.709 ODU-2.5G  G.709 ODUk
>>>>>
>>>>>                                      (k=2,3)
>>>>>
>>>>>                    (IANA to update Type field)
>>>>>
>>>>>             TBA8   G.709 ODU-1.25G G.709 ODUk
>>>>>
>>>>>                                      (k=1,2,3)
>>>>>
>>>>>     0x21    TBA8   G.709 ODU-1.25G G.709 ODUk
>>>>>
>>>>>                                      (k=2,3,4)
>>>>>
>>>>>             TBA9   G.709 ODU-Any   G.709 ODUk
>>>>>
>>>>>                                    (k=2,3)
>>>>>
>>>>>     0x55           No standard value
>>>>>
>>>>>     0x66           No standard value
>>>>>
>>>>>     0x80-0x8F      No standard value
>>>>>
>>>>>     0xFD    TBA10  Null Test       G.709 ODUk
>>>>>
>>>>>     0xFE    TBA11  Random Test     G.709 ODUk
>>>>>
>>>>>     0xFF           No standard value
>>>>>
>>>>>  
>>>>>
>>>>> Note that there are a few differences with Fatai's list, which doesn't
>>>>>
>>>>> format well in e-mail, but is available in the archive
>>>>>
>>>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html
>>>>>
>>>>>  
>>>>>
>>>>> Please speak up if you think the above is not aligned with prior
>>>>>
>>>>> consensus or if you have an issue with any of the above.
>>>>>
>>>>>  
>>>>>
>>>>> Much thanks,
>>>>>
>>>>> Lou
>>>>>
>>>>>  
>>>>>
>>>>>  
>>>>>
>>>>> On 5/20/2013 5:09 AM, Fatai Zhang wrote:
>>>>>
>>>>>> Hi Lou,
>>>>>
>>>>>>
>>>>>
>>>>>>  
>>>>>
>>>>>>
>>>>>
>>>>>> I think my mail on March 13rd may have answered your following comments.
>>>>>
>>>>>> My response quoted as follows.
>>>>>
>>>>>>
>>>>>
>>>>>>  
>>>>>
>>>>>>
>>>>>
>>>>>> In addition, if people look at the full list that I provided, I think
>>>>>
>>>>>> people can realize that RFC4328 (section 3.1.3) used the same approach
>>>>>
>>>>>> as the current approach of this draft (ie., 1:1 mapping between GPIDs
>>>>>
>>>>>> and payload types defined by G.709), ie., we are following what RFC4328
>>>>>
>>>>>> did.
>>>>>
>>>>>>
>>>>>
>>>>>>  
>>>>>
>>>>>>
>>>>>
>>>>>> BTW, I am not sure if we need spend so much on discussing this point
>>>>>
>>>>>> (because there is no issue to stick to the data plane by using the
>>>>>
>>>>>> current approach of this draft).
>>>>>
>>>>>>
>>>>>
>>>>>>  
>>>>>
>>>>>>
>>>>>
>>>>>> ======================================================================================================================
>>>>>
>>>>>>
>>>>>
>>>>>> (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 17, 2013 11:16 PM
>>>>>
>>>>>> To: Fatai Zhang
>>>>>
>>>>>> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP;
>>>>>
>>>>>> [e-mail]
>>>>>
>>>>>> Subject: Re: R: Closing G.709 open issues
>>>>>
>>>>>>
>>>>>
>>>>>>  
>>>>>
>>>>>>
>>>>>
>>>>>> 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
>>>>>
>>>>>>
>>>>>
>>>>>>  
>>>>>
>>>>>>
>>>>>
>>>>>>  
>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> CCAMP mailing list
>>>>>
>>>>> [e-mail]
>>>>>
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>>
>>>
>>>
> 
> 
> 
>