http://permalink.gmane.org/gmane.ietf.ccamp hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org 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., </pre> Fatai Zhang 2013-05-24T01:01:07 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 be</pre> Lou Berger 2013-05-23T21:07:05 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 w</pre> Khuzema Pithewan 2013-05-23T19:15:51 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 wha</pre> Lou Berger 2013-05-23T16:14:36 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 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</pre> Fatai Zhang 2013-05-23T02:38:40 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 C</pre> Fatai Zhang 2013-05-23T02:35:14 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 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 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 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 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 mu</pre> Fatai Zhang 2013-05-23T01:13:40 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 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 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 http://permalink.gmane.org/gmane.ietf.ccamp/12227 <pre>It should be blindingly obvious to the informed reader that 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-22T00:45:12 http://permalink.gmane.org/gmane.ietf.ccamp/12226 <pre>John, Great. It seems we agree that it shouldn't have been necessary to discuss this point so many times, and that the additional text doesn't change the field definition. It is informative narrative after all. Now that said, can you live with the revised "overly precise" text so that we can move forward (and ensure we're not back here again)? Lou On May 21, 2013 4:23:37 PM John E Drake &lt;jdrake&lt; at &gt;juniper.net&gt; wrote: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Lou Berger 2013-05-22T00:38:16 http://permalink.gmane.org/gmane.ietf.ccamp/12225 <pre>Lou, The question that has always been is whether signaling needed to include an explicit TSG filed and the answer has always been no because it can be derived from other fields. The text I proposed makes that derivation explicit and unambiguous. The additional text you are proposing adds neither clarity nor information. 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-21T20:23:37 http://permalink.gmane.org/gmane.ietf.ccamp/12224 <pre>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 </pre> Lou Berger 2013-05-21T13:16:57 http://permalink.gmane.org/gmane.ietf.ccamp/12223 <pre>John, Really? You're joking right? As I said to Fatai: My feeling is that there have been too many "surprises" on the 709 documents in areas that I thought were ... 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. The particular point of the ambiguity/implicit nature of determining TSG from length has been brought up at least three times. (Note, by others in the WG -- this is not my concern.) Each time the consensus from the discussion is to leave as is, but no or only minimal changes were made to the document. I opened the trac ticket to ensure that the consensus was documented in the draft and that we don't have to yet again revisit this topic -- which *is* my concern. So, the revised text addresses your concern of </pre> Lou Berger 2013-05-21T12:37:09 http://permalink.gmane.org/gmane.ietf.ccamp/12222 <pre>What is behind your preoccupation with enumerating all possible combinations of length &amp; TSG? Do you have trouble with arithmetic? Sent from my iPhone On May 20, 2013, at 1:42 PM, "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-21T02:30:30 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.ccamp