gmane.ietf.ccamp http://blog.gmane.org/gmane.ietf.ccamp hourly 1 1901-01-01T00:00+00:00 Gmane http://gmane.org/img/gmane-25t.png http://gmane.org Re: R: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) http://permalink.gmane.org/gmane.ietf.ccamp/12249 <pre>Sergio, On 5/24/2013 11:54 AM, BELOTTI, SERGIO (SERGIO) wrote: 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? Is this a different case? If yes, how so? (Do you have a data plane reference?) Thanks, Lou _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Lou Berger 2013-05-24T16:33:00 Re: Closing Issue #49 (Was: Re: R: Closing G.709 openissues) http://permalink.gmane.org/gmane.ietf.ccamp/12248 <pre>Thanks Lou. Appreciate the pointer to RFC4328. I did miss it. Regards Khuzema -----Original Message----- From: Lou Berger [mailto:lberger&lt; at &gt;labn.net] Sent: Friday, May 24, 2013 6:54 PM To: Khuzema Pithewan Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3&lt; at &gt;tools.ietf.org Subject: Re: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) Khuzema, Glad to hear there's no actual use case / issue to be addressed. As to your general comments/observations, my perspective is that given the generic cross-technology nature of GMPLS there often isn't a direct 1:1 mapping of switching technology semantics to GMPLS semantics. As to your specific (theoretical) concern, I think you might have missed the following IANA controlled (and RFC4328 defined) ranges: 31744-32767 Experimental Usage/temporarily 32768-65535 Reserved Lou On 5/24/2013 5:32 AM, Khuzema Pithewan wrote: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Khuzema Pithewan 2013-05-24T16:27:46 R: Closing Issue #49 (Was: Re: R: Closing G.709 openissues) http://permalink.gmane.org/gmane.ietf.ccamp/12247 <pre>Hi, Please take care anyway this solution does not consider two cases: G.7041 and G.709, defines respectively: 10GbE --&gt; GFP-F (G.7041, Table 6-3: UPI=0x13 [ Frame-mapped 64B/66B encoded Ethernet, including the Ethernet frame preamble ]) 10GbE--&gt; 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&lt; at &gt;ietf.org [mailto:ccamp-bounces&lt; at &gt;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&lt; at &gt;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: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> BELOTTI, SERGIO (SERGIO 2013-05-24T15:54:46 Re: Closing Issue #49 (Was: Re: R: Closing G.709 openissues) http://permalink.gmane.org/gmane.ietf.ccamp/12246 <pre>Khuzema, Glad to hear there's no actual use case / issue to be addressed. As to your general comments/observations, my perspective is that given the generic cross-technology nature of GMPLS there often isn't a direct 1:1 mapping of switching technology semantics to GMPLS semantics. As to your specific (theoretical) concern, I think you might have missed the following IANA controlled (and RFC4328 defined) ranges: 31744-32767 Experimental Usage/temporarily 32768-65535 Reserved Lou On 5/24/2013 5:32 AM, Khuzema Pithewan wrote: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Lou Berger 2013-05-24T13:24:16 Re: Closing Issue #49 (Was: Re: R: Closing G.709 openissues) http://permalink.gmane.org/gmane.ietf.ccamp/12245 <pre>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: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Lou Berger 2013-05-24T13:15:25 Re: Closing Issue #49 (Was: Re: R: Closing G.709 openissues) http://permalink.gmane.org/gmane.ietf.ccamp/12244 <pre>Hi Lou, -&gt; Are you just trying to be exhaustive in your definitions, or do you have an actual use case? If the latter, can you elaborate on your desired use? There is no actual usecase, rather intent is to align dataplane spec with control plane spec. In reality, there may not arise any backward compatibility issue in foreseeable future, because GPid range is very large (16 bits) and vendor specific client payload may choose to use very high Gpid value, where standard defined GPid may not reach. Having said that, I am not sure, why RFC 3471 defines 4 Gpid values (1-4) as reserved. What purpose does it serve? Either we define reserved values that underlying dataplane defines, or we don't define at all. If we have convention of defining reserved GPids, then why not match it with data plane spec. However, I believe defining or not defining reserved value, is not going to have any material impact on the way standard will be implemented. I am fine either way! Regards Khuzema -----Original Message----- From: Lou Berger [mailto:lberger&lt; at &gt;labn.net] Sent: Friday, May 24, 2013 2:37 AM To: Khuzema Pithewan Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3&lt; at &gt;tools.ietf.org Subject: Re: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) On 5/23/2013 3:15 PM, Khuzema Pithewan wrote: Khuzema, I agree. Vendors have always used (and continue to use) standard code points for proprietary purposes at their own peril. There is nothing new or unique about this in the context of the documents we're discussing. Another way to look at it is to ask/answer the following: What about this draft (supporting [G709-2012]) is different from [RFC4328] (supporting g709-2001) or any other technology supported by GMPLS that has experimental, reserved, and/or unavailable client types? Why? [RFC4328] didn't standardize G-PIDs for the following G.709-2001 defined PTs: PT Interpretation 0x01 Experimental mapping \ 0x55 Not available 0x66 Not available 0x80-0x8F Reserved codes for proprietary use 0xFF Not available Are you just trying to be exhaustive in your definitions, or do you have an actual use case? If the latter, can you elaborate on your desired use? BTW you might want to look at the current IANA G-PID assignments before answering. I suspect you'll find that you can address your concerns using existing assignments. Thanks, Lou _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Khuzema Pithewan 2013-05-24T09:32:22 Re: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) http://permalink.gmane.org/gmane.ietf.ccamp/12243 <pre>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&lt; at &gt;labn.net] Sent: Friday, May 24, 2013 12:15 AM To: Fatai Zhang Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3&lt; at &gt;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): 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: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Fatai Zhang 2013-05-24T01:01:07 Re: Closing Issue #49 (Was: Re: R: Closing G.709 openissues) http://permalink.gmane.org/gmane.ietf.ccamp/12242 <pre> On 5/23/2013 3:15 PM, Khuzema Pithewan wrote: Khuzema, I agree. Vendors have always used (and continue to use) standard code points for proprietary purposes at their own peril. There is nothing new or unique about this in the context of the documents we're discussing. Another way to look at it is to ask/answer the following: What about this draft (supporting [G709-2012]) is different from [RFC4328] (supporting g709-2001) or any other technology supported by GMPLS that has experimental, reserved, and/or unavailable client types? Why? [RFC4328] didn't standardize G-PIDs for the following G.709-2001 defined PTs: PT Interpretation 0x01 Experimental mapping \ 0x55 Not available 0x66 Not available 0x80-0x8F Reserved codes for proprietary use 0xFF Not available Are you just trying to be exhaustive in your definitions, or do you have an actual use case? If the latter, can you elaborate on your desired use? BTW you might want to look at the current IANA G-PID assignments before answering. I suspect you'll find that you can address your concerns using existing assignments. Thanks, Lou _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Lou Berger 2013-05-23T21:07:05 Re: Closing Issue #49 (Was: Re: R: Closing G.709 openissues) http://permalink.gmane.org/gmane.ietf.ccamp/12241 <pre>Hi Lou, -&gt; C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. Let say some vendor uses reserved (80-8F, which will never be standardized by ITU, as per Note4 in Table 15-8) payload code point and uses some GPid 'x' in Control plane for that code point. Now if in future, Control plane defines x for some other client. There will be backward compatibility issues. Since it is clearly mentioned that these 16 code points in dataplane, will not standardized, is a standardization in way, which must be followed up in control plane by reserving 16 GPids for the purpose. Regds Khuzema -----Original Message----- From: Lou Berger [mailto:lberger&lt; at &gt;labn.net] Sent: Tuesday, May 21, 2013 6:47 PM To: CCAMP Cc: draft-ietf-ccamp-gmpls-signaling-g709v3&lt; at &gt;tools.ietf.org Subject: 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 &amp; 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: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Khuzema Pithewan 2013-05-23T19:15:51 Re: Closing Issue #49 (Was: Re: R: Closing G.709 openissues) http://permalink.gmane.org/gmane.ietf.ccamp/12240 <pre>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): 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: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Lou Berger 2013-05-23T16:14:36 Re: Confirming plan for Issue #48: (Was: Closing G.709 open issues) http://permalink.gmane.org/gmane.ietf.ccamp/12238 <pre>Lou and John, Thanks. Happy to see that you both provided the same proposed text. Best Regards Fatai -----Original Message----- From: John E Drake [mailto:jdrake&lt; at &gt;juniper.net] Sent: Thursday, May 23, 2013 10:10 AM To: Fatai Zhang; Lou Berger Cc: CCAMP Subject: RE: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) Fatai, Length (12 bits): indicates the number of bits of the Bit Map field, i.e., the number of TS in the HO ODUk link. The TS granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's rate by the value of the Length field. In the context of [G709-2012], the values of 4 and 16 indicate a TS granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps. Yours Irrespectively, John _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Fatai Zhang 2013-05-23T02:45:16 Re: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) http://permalink.gmane.org/gmane.ietf.ccamp/12237 <pre>Hi Lou, An typed error should be corrected: For 0x05, why you think that RFC4328 does not cover it (ie., G-PID=54)? Best Regards Fatai From: Fatai Zhang Sent: Thursday, May 23, 2013 10:35 AM To: 'Lou Berger'; CCAMP Cc: draft-ietf-ccamp-gmpls-signaling-g709v3&lt; at &gt;tools.ietf.org Subject: RE: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues) 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 code defined in G.709 G-PID LSP Encoding Note Interpretation from 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) Or 55(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) Or 58(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) Or 58(Suggested by Lou) G.709 ODUk (k=0) ditto FC-100 mapping into OPU0, see clause 17.7.1 0x0D 67(TBA) Or 58(Suggested by Lou) G.709 ODUk (k=1) ditto FC-200 mapping into OPU1, see clause 17.7.2 0x0E 68(TBA) Or 58(Suggested by Lou) G.709 ODUflex ditto FC-400 mapping into OPUflex, see clause 17.9 0x0F 69(TBA) Or 58(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) Or 56(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 Or TBA(Suggested by Lou) Not needed NULL test signal mapping, see clause 17.5.1 FE None Or TBA(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&lt; at &gt;ietf.org [mailto:ccamp-bounces&lt; at &gt;ietf.org] On Behalf Of Lou Berger Sent: Tuesday, May 21, 2013 9:17 PM To: CCAMP Cc: draft-ietf-ccamp-gmpls-signaling-g709v3&lt; at &gt;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 &amp; 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: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Fatai Zhang 2013-05-23T02:38:40 Re: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) http://permalink.gmane.org/gmane.ietf.ccamp/12236 <pre>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 code defined in G.709 G-PID LSP Encoding Note Interpretation from 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) Or 55(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) Or 58(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) Or 58(Suggested by Lou) G.709 ODUk (k=0) ditto FC-100 mapping into OPU0, see clause 17.7.1 0x0D 67(TBA) Or 58(Suggested by Lou) G.709 ODUk (k=1) ditto FC-200 mapping into OPU1, see clause 17.7.2 0x0E 68(TBA) Or 58(Suggested by Lou) G.709 ODUflex ditto FC-400 mapping into OPUflex, see clause 17.9 0x0F 69(TBA) Or 58(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) Or 56(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 Or TBA(Suggested by Lou) Not needed NULL test signal mapping, see clause 17.5.1 FE None Or TBA(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&lt; at &gt;ietf.org [mailto:ccamp-bounces&lt; at &gt;ietf.org] On Behalf Of Lou Berger Sent: Tuesday, May 21, 2013 9:17 PM To: CCAMP Cc: draft-ietf-ccamp-gmpls-signaling-g709v3&lt; at &gt;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 &amp; 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: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Fatai Zhang 2013-05-23T02:35:14 Re: Confirming plan for Issue #48: (Was: Closing G.709 open issues) http://permalink.gmane.org/gmane.ietf.ccamp/12235 <pre>Fatai, Length (12 bits): indicates the number of bits of the Bit Map field, i.e., the number of TS in the HO ODUk link. The TS granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's rate by the value of the Length field. In the context of [G709-2012], the values of 4 and 16 indicate a TS granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps. Yours Irrespectively, John _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> John E Drake 2013-05-23T02:10:09 Re: Closing Issue #49 (Was: Re: R: Closing G.709 openissues) http://permalink.gmane.org/gmane.ietf.ccamp/12234 <pre>Hi Lou, I really missed this mail. I will respond there. Best Regards Fatai -----Original Message----- From: Lou Berger [mailto:lberger&lt; at &gt;labn.net] Sent: Thursday, May 23, 2013 9:41 AM To: Fatai Zhang Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3&lt; at &gt;tools.ietf.org Subject: Re: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) Fatai, I think you missed the following: http://www.ietf.org/mail-archive/web/ccamp/current/msg14861.html As stated in that message: (probably best to respond to that message if you have a comment on it.) Lou On 5/22/2013 9:13 PM, Fatai Zhang wrote: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Fatai Zhang 2013-05-23T02:05:54 Re: Closing Issue #49 (Was: Re: R: Closing G.709 openissues) http://permalink.gmane.org/gmane.ietf.ccamp/12233 <pre>Fatai, I think you missed the following: http://www.ietf.org/mail-archive/web/ccamp/current/msg14861.html As stated in that message: (probably best to respond to that message if you have a comment on it.) Lou On 5/22/2013 9:13 PM, Fatai Zhang wrote: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Lou Berger 2013-05-23T01:41:20 Re: Confirming plan for Issue #48: (Was: Closing G.709 open issues) http://permalink.gmane.org/gmane.ietf.ccamp/12232 <pre>drop the OLD text (identified in the trac issue) &amp; replace Length field definition with: Lou On 5/22/2013 8:55 PM, Fatai Zhang wrote: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Lou Berger 2013-05-23T01:27:54 Re: R: Closing G.709 open issues http://permalink.gmane.org/gmane.ietf.ccamp/12231 <pre>Hi Lou and all, I would like to double check again on the original point 2. I would assume the WG is happy with the proposed approach and then conclude the discussion on point 2 if there is no more comment until this Friday. Note that I think more people have shown their support on the proposed approach. Best Regards Fatai From: Fatai Zhang [mailto:zhangfatai&lt; at &gt;huawei.com] Sent: Monday, May 20, 2013 5:09 PM To: Lou Berger Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3&lt; at &gt;tools.ietf.org Subject: RE: R: Closing G.709 open issues Hi Lou, I think my mail on May 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 proposed approach (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 time on discussing this point (because there is no issue to stick to the data plane by using the proposed approach). ====================================================================================================================== (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&lt; at &gt;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&lt; at &gt;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 &amp; 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 &amp; agreed to by the WG. Can you answer the following: Much thanks, Lou _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Fatai Zhang 2013-05-23T01:13:40 Re: Confirming plan for Issue #48: (Was: Closing G.709 open issues) http://permalink.gmane.org/gmane.ietf.ccamp/12230 <pre>Hi Lou and John, Thanks for your discussion on providing the proposed text. However, I am lost by the discussion. What is the final proposed text? I hope someone can finalize it. I think it is time to conclude the discussion on this point (the original point 1). Best Regards Fatai -----Original Message----- From: John E Drake [mailto:jdrake&lt; at &gt;juniper.net] Sent: Thursday, May 23, 2013 2:01 AM To: Lou Berger Cc: Fatai Zhang; CCAMP Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues) Bummer Sent from my iPhone On May 22, 2013, at 10:45 AM, "Lou Berger" &lt;lberger&lt; at &gt;labn.net&gt; wrote: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Fatai Zhang 2013-05-23T00:55:04 Re: Confirming plan for Issue #48: (Was: Closing G.709 open issues) http://permalink.gmane.org/gmane.ietf.ccamp/12229 <pre>Bummer Sent from my iPhone On May 22, 2013, at 10:45 AM, "Lou Berger" &lt;lberger&lt; at &gt;labn.net&gt; wrote: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> John E Drake 2013-05-22T18:00:49 Re: Confirming plan for Issue #48: (Was: Closing G.709 open issues) http://permalink.gmane.org/gmane.ietf.ccamp/12228 <pre>I'm empathetic with the addition, but suspect it's best not to put the first 10 words in the draft... Lou On 5/21/2013 8:45 PM, John E Drake wrote: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Lou Berger 2013-05-22T17:28:41 Search Engine Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.ccamp