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

"BELOTTI, SERGIO (SERGIO)" <sergio.belotti@alcatel-lucent.com> Fri, 24 May 2013 15:55 UTC

Return-Path: <sergio.belotti@alcatel-lucent.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647A721F9612 for <ccamp@ietfa.amsl.com>; Fri, 24 May 2013 08:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.649
X-Spam-Level:
X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XY4QfmBDlWWT for <ccamp@ietfa.amsl.com>; Fri, 24 May 2013 08:55:10 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id C573621F9051 for <ccamp@ietf.org>; Fri, 24 May 2013 08:55:07 -0700 (PDT)
Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r4OFsxN8024973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 May 2013 10:55:00 -0500 (CDT)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r4OFswF5014673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 May 2013 11:54:59 -0400
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 24 May 2013 11:54:58 -0400
Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.233]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 24 May 2013 17:54:47 +0200
From: "BELOTTI, SERGIO (SERGIO)" <sergio.belotti@alcatel-lucent.com>
To: Lou Berger <lberger@labn.net>
Thread-Topic: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)
Thread-Index: AQHOWIDa0uGEPb8n5EC3v4f6WF1pRZkUfDvQ
Date: Fri, 24 May 2013 15:54:46 +0000
Message-ID: <B9FEE68CE3A78C41A2B3C67549A96F4802E44F@FR711WXCHMBA05.zeu.alcatel-lucent.com>
References: <518A82D9.7080508@labn.net> <518CED28.30303@labn.net> <F82A4B6D50F9464B8EBA55651F541CF84317B943@SZXEML552-MBX.china.huawei.com> <B9FEE68CE3A78C41A2B3C67549A96F4802BCBD@FR711WXCHMBA05.zeu.alcatel-lucent.com> <F82A4B6D50F9464B8EBA55651F541CF84317BEA2@SZXEML552-MBX.china.huawei.com> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <B9FEE68CE3A78C41A2B3C67549A96F4802C534@FR711WXCHMBA05.zeu.alcatel-lucent.com> <5193A26A.1090005@labn.net> <F82A4B6D50F9464B8EBA55651F541CF84317D2BA@SZXEML552-MBX.china.huawei.com> <519649B4.5060408@labn.net> <F82A4B6D50F9464B8EBA55651F541CF84319607D@SZXEML552-MBX.china.huawei. com> <519B73C9.2030308@labn.net> <F82A4B6D50F9464B8EBA55651F541CF84319B82E@SZXEML552-MBX.china.huawe i.com> <519E406C.9030008@labn.net> <F82A4B6D50F9464B8EBA55651F541CF84319BFF2@SZXEML552-MBX.china.huawei.com> <519F67ED.3040701@labn.net>
In-Reply-To: <519F67ED.3040701@labn.net>
Accept-Language: it-IT, en-US
Content-Language: it-IT
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Cc: CCAMP <ccamp@ietf.org>, "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" <draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org>
Subject: [CCAMP] R: Closing Issue #49 (Was: Re: R: Closing G.709 open issues)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2013 15:55:24 -0000

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

10GbE--> extended OPU2/ODU2 (G.709, Table 15-8: PT=0x09 [ GFP mapping into Extended
OPU2 payload, see clause 17.4.1 ])

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 +39 (039) 6863033
-----Messaggio originale-----
Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Lou Berger
Inviato: venerdì 24 maggio 2013 15.15
A: Fatai Zhang
Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
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:lberger@labn.net] 
> Sent: Friday, May 24, 2013 12:15 AM
> To: Fatai Zhang
> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
> 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: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
>> Of Lou Berger
>> Sent: Tuesday, May 21, 2013 9:17 PM
>> To: CCAMP
>> Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
>> 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:lberger@labn.net]
>>
>>> Sent: Friday, May 17, 2013 11:16 PM
>>
>>> To: Fatai Zhang
>>
>>> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP;
>>
>>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
>>
>>> 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
>>
>> CCAMP@ietf.org
>>
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
> 
> 
> 
> 
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp