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

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

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