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/12212 <pre>John, I guess you haven't been paying attention! The rewrite originated from Daniele, was tweaked by me and then fixed by Fatai. Do you have an alternate proposal to address issue#48? Issue #48="In signaling document section 6: Clarify related text [i.e., the OLD text] to unambiguously identify the relationship between label length and TSG." Thanks, Lou On 5/17/2013 1:15 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-17T20:32:31 http://permalink.gmane.org/gmane.ietf.ccamp/12211 <pre>Lou, I think the original text is fine and your attempted re-write completely mangled its meaning. The label is a bit vector whose length is equal to the ODUk rate / TSG. Irrespectively Yours, John _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> John E Drake 2013-05-17T17:15:23 http://permalink.gmane.org/gmane.ietf.ccamp/12210 <pre>Authors/WG, From the mail on the list it seems to me that we've reached closure on Issue #48: "Document no explicit indication of TSG in the label" (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48). I'd like to confirm my reading. As I read the list, this issue will be resolved by making the following change to draft-ietf-ccamp-gmpls-signaling-g709v3. OLD Note that the Length field in the label format MAY be used to indicate the TS type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps) since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In some cases when there is no Link Management Protocol (LMP) or routing to make the two end points of the link to know the TSG, the TSG information used by another end can be deduced from the label format. For example, for HO ODU2 link, the value of the length filed will be 4 or 8, which indicates the TS granularity is 2.5Gbps or 1.25Gbps, respectively. NEW Please note that the TS granularity of an HO ODUk can be inferred </pre> Lou Berger 2013-05-17T16:17:02 http://permalink.gmane.org/gmane.ietf.ccamp/12209 <pre>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 On 5/17/2013 3:58 AM, Fatai Zhang wrote:&gt; Hi Lou, GFP) second LC. checked the GPIDs defined in [RFC4328], I think the following new GPIDs (values co</pre> Lou Berger 2013-05-17T15:16:04 http://permalink.gmane.org/gmane.ietf.ccamp/12208 <pre>Hi Lou, I thought it should be sufficient for me to identify the *updated* and *new* G-PIDs in this draft (I compared [G.709-2003] and [G.709-2012], and checked RFC4328), but I would be happy to provide a full list for your request. Please see the list below, and the new payload types introduced by [G.709-2012] (and the corresponding new G-PIDs defined in this draft) are in the light blue cells. Please check if there is anything missed or wrong. Note that GPIDs like 32,47,49-52 have been updated in this draft. Note that we as authors welcome any contributors for their contribution. For you convenience, I also attached the word document. G-PIDs vs Payload types defined in Table 15-8 of G.709 G-PID LSP Encoding Payload Type in Hex code defined in G.709 Note Interpretation from G.709 None 0x01 Not needed Experimental mapping (Note 3) 49 G.709 ODUk, G.709 OCh 0x02 1)G-PID defined in RFC4328; 2) Updated in this draft. Asynchronous CBR mapping, see clause 17.2 </pre> Fatai Zhang 2013-05-17T07:58:17 http://permalink.gmane.org/gmane.ietf.ccamp/12207 <pre>Sergio/Fatai, On 5/15/2013 7:54 AM, BELOTTI, SERGIO (SERGIO) wrote: And, based on the discussion, I (to be clear, as WG chair) have revised the request by asking: "that the editors of the draft provide (and include in the document) a full list of Payload Type values (with the 0x value prefix or the values in decimal) and their corresponding G-PID values. Also including Encoding Type as you [Fatai] have below is a good addition -- great idea!" Given the level of discussion of this thread, I think this is a completely reasonable way to avoid future confusion, particularly in implementations. Do the Authors/Editor need help in generating this complete list? Do the Authors/Editor want (me) to issue a call for input on this list? I suspect some in WG will be happy to jump in as it's an easy way to get added as a contributor to the signaling draft. So I went looking for past discussions on this, and this is what I find: - From http://www.ietf.org/mail-archive/web/ccamp/current/msg13598.htm</pre> Lou Berger 2013-05-15T14:57:46 http://permalink.gmane.org/gmane.ietf.ccamp/12206 <pre>We (as authors" were asked to cope with the remaining issues to start second LC. One these "remaining issues" was as fro Lou's mil of May 9th 2) Verify that the complete list of G-PIDs are defined [SIGNALING] In signaling document section 4, verify that all payload types defined in G.709 (Summarized in Table 15-8) can be represented. This issue can be resolved via an update or message to the list stating that the verification took place. This is concluded by Fatai answer regarding G-PID check and 1:1 mapping. FATAI&gt; For point 2), I compared [G.709-2003] and [G.709-2012], and checked the GPIDs defined in [RFC4328], I think the following new GPIDs (values could be 59-79) should be added (besides updating some GPIDs defined in RFC4328, like 32,47,49-52): Value G-PID Type LSP Encoding Type ----- ---------- ----------------- 59(TBA) G.709 ODU-1.25G G.709 ODUk 60(TBA) G.709 ODU-any G.709 ODUk 61(TBA) PCS </pre> BELOTTI, SERGIO (SERGIO 2013-05-15T11:54:57 http://permalink.gmane.org/gmane.ietf.ccamp/12205 <pre>Daniele, On May 15, 2013 4:20:25 AM Daniele Ceccarelli &lt;daniele.ceccarelli&lt; at &gt;ericsson.com&gt; wrote: We must be thinking of different threads. The one I'm thinking of started with the comment along the lines of "why only some G-PIDs represented in the ADAPTATION object" and concluded with the agreement to drop the object and follow the current generic approach as well as look into a non-OTN specific solution in a new draft. At least that's how I remember it.... humm, this seems inconsistent with Fatai recently suggesting that i was asking for a "non-grouped" approach. At the time, I was really just thinking about the values missing in the list I sent out. I don't recall any other discussion on moving away from the past 709 G-PID assignment approach. It looks like we both/all should take a look at the archives to refresh our memories.... Thanks, Lou _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Lou Berger 2013-05-15T11:22:23 http://permalink.gmane.org/gmane.ietf.ccamp/12204 <pre>Hi Lou, Just a bit. If i correctly remember we agreed to solve the routing issu in a generic approach, not the signaling one. It is possible to assume that the adaptation is a known info to the operator and hence that the advertisement can be postponed and addressed in a generic way but it needs to be signaled. This is an hortogonal issue with respect to the mapping of G-PID, which has always been assumed to be 1:1 with G.709 values. The 1:1 *mapping* approach used by Fatai is different from the *mapping" protocol like GFP, AMP that we discussed before. BR Daniele, Sergio, Fatai _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Daniele Ceccarelli 2013-05-15T08:20:25 http://permalink.gmane.org/gmane.ietf.ccamp/12203 <pre>Young, Great. Sounds like we're in sync on future/planned/outstanding next steps. Lou On 5/14/2013 1:03 PM, Leeyoung wrote: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Lou Berger 2013-05-14T17:14:54 http://permalink.gmane.org/gmane.ietf.ccamp/12202 <pre>Hi Lou, There are no outstanding actions on the WSON documents. We only need to update signaling draft based on the last IETF meeting discussion, which will be shortly updated. Thanks. Young -----Original Message----- From: Lou Berger [mailto:lberger&lt; at &gt;labn.net] Sent: Tuesday, May 14, 2013 11:18 AM To: Leeyoung Cc: ccamp&lt; at &gt;ietf.org Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-18.txt Young/WSON authors, Can you confirm that there are no other outstanding actions on the WSON documents other than an update to the signaling document (based on prior discussions)? Much thanks, Lou On 5/13/2013 2:55 PM, Leeyoung wrote: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Leeyoung 2013-05-14T17:03:46 http://permalink.gmane.org/gmane.ietf.ccamp/12201 <pre>Young/WSON authors, Can you confirm that there are no other outstanding actions on the WSON documents other than an update to the signaling document (based on prior discussions)? Much thanks, Lou On 5/13/2013 2:55 PM, Leeyoung wrote: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Lou Berger 2013-05-14T16:17:30 http://permalink.gmane.org/gmane.ietf.ccamp/12200 <pre>Fatai, Sergio, I haven't had time to go find the old mail covering the topic you mentioned (which is why I didn't respond yesterday): My memory is that the consensus at the time was that G.709 would continue to use the current generic approach to edge adaptation &amp; G-PIDs, and that (some of) the G.709 authors would submit a draft that would address adaptation in a generic fashion. Do you think this characterization is mistaken? (If so, time to go searching for the old discussion, if not we can move on.) Assuming no, then it seems to me that you are going against this discussion &amp; consensus by now introducing a 1:1/bandwidth specific mapping approach. Do you disagree? If not, do you think there's justification to reopen this discussion? Independent of the mapping approach and in order to ensure this issue is closed and does not again resurface, I also request (again) that the editors of the draft provide (and include in the document) a full list of Payload Type values (with the 0x value prefix or the va</pre> Lou Berger 2013-05-14T14:00:34 http://permalink.gmane.org/gmane.ietf.ccamp/12199 <pre>Hi all, Thanks, Sergio. I would like to double check if everything is OK before we update the signaling draft. I would assume the WG is happy with 1:1 mapping approach and the new GPIDs listed below if there is no more comment until this Wed. Best Regards Fatai -----Original Message----- From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti&lt; at &gt;alcatel-lucent.com] Sent: Monday, May 13, 2013 3:45 PM To: Fatai Zhang; Lou Berger Cc: Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3&lt; at &gt;tools.ietf.org; draft-ietf-ccamp-otn-g709-info-model&lt; at &gt;tools.ietf.org Subject: R: Closing G.709 open issues Hi Fatai, I agree with you, for both point 1 and 2. Best Regards Sergio Belotti Sergio- System Architect ALCATE-LUCENT Optics Division via Trento 30 Vimercate (MB) - Italy phone +39 (039) 6863033 -----Messaggio originale----- Da: Fatai Zhang [mailto:zhangfatai&lt; at &gt;huawei.com] Inviato: lunedì 13 maggio 2013 5.33 A: Lou Berger Cc: Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3&lt; at &gt;tools.</pre> Fatai Zhang 2013-05-14T05:53:03 http://permalink.gmane.org/gmane.ietf.ccamp/12198 <pre>This WG Last Call has ended. I will prepare the publication request. Thanks, Deborah From: ccamp-bounces&lt; at &gt;ietf.org [mailto:ccamp-bounces&lt; at &gt;ietf.org] On Behalf Of BRUNGARD, DEBORAH A Sent: Friday, April 26, 2013 1:35 PM To: ccamp&lt; at &gt;ietf.org Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-swcaps-update-01.txt All, This starts a two-week working group last call on draft-ietf-ccamp-swcaps-update-01.txt. This working group last call ends May 10th, 2013. Please send your comments to the CCAMP mailing list. Deborah (and Lou) _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> BRUNGARD, DEBORAH A 2013-05-13T20:21:41 http://permalink.gmane.org/gmane.ietf.ccamp/12197 <pre>Hi, This update (v.18) revived the expired draft with the added clarification texts thanks to Lou. The major changes are as follows: 1. &lt;ClientSignalList&gt; is added in &lt;OutputConstraints&gt; in Section 5.2 as follows: &lt;OutputConstraints&gt; := &lt;SharedOutput&gt; [&lt;OpticalInterfaceClassList&gt;][&lt;ClientSignalList&gt;] 2. Clarified the scope of Section 6 (Link Advertisement) that these additional link characteristics defined in Section 6 only applies to line side ports of WDM system or add/drop ports pertaining to Resource Pool (e.g., Regenerator or Wavelength Converter Pool) and not intended for ingress/egress tributary ports. Let me know if you have any question on this change or any comment on the updated draft. Regards, Young -----Original Message----- From: ccamp-bounces&lt; at &gt;ietf.org [mailto:ccamp-bounces&lt; at &gt;ietf.org] On Behalf Of internet-drafts&lt; at &gt;ietf.org Sent: Monday, May 13, 2013 1:49 PM To: i-d-announce&lt; at &gt;ietf.org Cc: ccamp&lt; at &gt;ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-info-18.txt A New</pre> Leeyoung 2013-05-13T18:55:49 http://permalink.gmane.org/gmane.ietf.ccamp/12196 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks Author(s) : Young Lee Greg M. Bernstein Dan Li Wataru Imajuku Filename : draft-ietf-ccamp-rwa-info-18.txt Pages : 28 Date : 2013-05-13 Abstract: This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspec</pre> internet-drafts< at >ietf.org 2013-05-13T18:48:57 http://permalink.gmane.org/gmane.ietf.ccamp/12195 <pre>Julien, I think you win on this one. Authors, Please add a '0x' prefix to any hexadecimal value in the draft. In other words: s/=2/=0x2 s/ 20/ 0x20 s/ 21/ 0x21 Lou On 5/13/2013 12:33 PM, Julien Meuric wrote: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Lou Berger 2013-05-13T17:29:54 http://permalink.gmane.org/gmane.ietf.ccamp/12194 <pre>Hi. On my right, a simple prefix that makes values clear and unambiguous at reading time, without the burden of references' context; on my left, 2 confusing statements that will no more be in mind when reading figures... I have often heard comments about RFC readability and the needed IETF background to understand what is not explicit: 2 more characters per figure would be both helpful and harmless. By the way, the IANA registry about GMPLS makes use of the '0x' prefix: http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml#gmpls-sig-parameters-8 Regards, Julien On 05/13/2013 12:59, Lou Berger wrote: _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Julien Meuric 2013-05-13T16:33:05 http://permalink.gmane.org/gmane.ietf.ccamp/12193 <pre> On May 13, 2013, at 6:59 AM, Lou Berger wrote: As a data point, OSPF RFCs and drafts always precede hexadecimal values with 0x. Of course, the OSPF WG has a heritage of the authors also being software developers. Unfortunately, I don't see any guidance here: http://www.rfc-editor.org/styleguide.html Thanks, Acee _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Acee Lindem 2013-05-13T11:36:11 http://permalink.gmane.org/gmane.ietf.ccamp/12192 <pre>Daniele, On 5/13/2013 4:03 AM, Daniele Ceccarelli wrote: I think the author's preference of not using the 0x prefix to hexadecimal representation is viable if it is clear in the document (as you mention below) and you can point to precedent of similar usage in existing RFCs. Have you checked / can you check to see if there's such? Assuming we go this way: I understand your intent, but I think you're actually stating exactly the opposite. How about, simply: Note that the Payload Types (PT) defined in [G709-2012], and repeated in this document, are provided in hexadecimal representation without the commonly used '0x' prefix. Lou _______________________________________________ CCAMP mailing list CCAMP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ccamp </pre> Lou Berger 2013-05-13T10:59:03 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.ccamp