Re: [CCAMP] Closing G.709 open issues

[Daniele Ceccarelli <[e-mail]>]

 Lou,

I want to close the OTN work more than anyone else :-)
I just expressed loud thinking due to last evolution in OTN data plane, but i said, no major issue and i'm fine with 1. Let's go with 1.

I'm fine with the text you're proposing.

Thanks
Daniele

>-----Original Message-----
>From: Lou Berger [mailto:[e-mail]] 
>Sent: giovedì 9 maggio 2013 19.21
>To: Daniele Ceccarelli
>Cc: Fatai Zhang; CCAMP; 
>[e-mail]; 
>[e-mail]
>Subject: Re: Closing G.709 open issues
>
>Daniele,
>	Please see below:
>
>On 5/9/2013 12:57 PM, Daniele Ceccarelli wrote:
>> Hi Lou,
>> 
>> Wrt point 1) (TSG) we have 2 options.
>> 
>> 1. leave the TSG being inferred by the label length and 
>propose new text (see below).
>> 2. add the TSG to the label.
>> 
>> Either solutions work for me, i just want to share some 
>thoughts raised during discussions with Sergio and Fred.
>> A. From an implementation point of view, in case of 
>multi-stage muxing 
>> multiple label lookups are needed to infer the TSG B. Future 
>proofness: we all know that TSG=10Gbps will be defined 
>shorthly. This might make the TSG infer from label length not feasible.
>> 
>
>Sigh, I keep thinking we're "almost done" on 709 and another 
>discussion pops up...
>
>So this is at least the third time we're discussing options 1 
>and 2.  In the prior times, we've always agreed to follow 1.  
>So I'll quote myself, from the last time around:
>   Revising past decisions is fine if there's good cause, such as new
>   information or issues identified/discovered...
>
>So let me ask, is there good cause to revisit this decision?
>
>> Again, for me both solutions 1. and 2. work, A. And B. might 
>not be major issues.
>> 
>> In case we go for 1. my proposed text is (feel free to amend):
>> 
>> "Please note that the TSG of the HO ODUk can be inferred 
>from the length of the label.
>> In those cases where there is no LMP imposing the TSG to be used 
>> between two ends of a link, Such information can be inferred 
>from the 
>> signaling. E.g. In a HO ODU link a label lenght value Of 4 
>would indicate TSG equal to 2,5Gbps while a value of 8 would 
>correspond to a 1.25Gbps TSG".
>
>Continuing in the case of 1, but how about:
>
>  Please note that the TS granularity of a HO ODUk can be inferred from
>  the length of the label. The values of 1, 4 and 16 indicate a TS
>  granularity of 2.5Gps, while the values 2, 7, 32 and 80 indicate a TS
>  granularity of 1.25Gps.
>
>Note that I added the length value of 1 based on the table on 
>page 7 of the framework draft, but 1 isn't listed as a valid 
>length value.  One of these is wrong. (I didn't spend the time 
>to figure out if the 1 needs to be added to valid list or 
>should be dropped from the suggested text.
>Figured one of the authors would know this.)
>
>Thanks,
>Lou
>
>> 
>> BR
>> Daniele
>> 
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: Lou Berger [mailto:[e-mail]]
>>> Sent: giovedì 9 maggio 2013 15.57
>>> To: Fatai Zhang
>>> Cc: CCAMP;
>>> [e-mail];
>>> [e-mail]
>>> Subject: Re: Closing G.709 open issues
>>>
>>>
>>> Just to be clear to all: My mail summarized the results of 
>>> discussions that occurred on the list whose results I believe 
>>> are not reflected in the current document set.  I identified 3 
>>> items, and hope I didn't miss anything from the ~200 related 
>>> messages on the list. I'm not trying to change any 
>>> conclusions, just ensure that they are documented.
>>>
>>> Fatai,
>>>
>>> See below for specific responses.
>>>
>>> On 5/9/2013 3:12 AM, Fatai Zhang wrote:
>>>> Hi Lou,
>>>>
>>>> For point 1), do you mean that you would like to have "TSG" field 
>>>> (ie., explicit indication) in the label format? Or just change the 
>>>> target text that you quoted?
>>>>
>>>
>>> This point was resolved in
>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html
>>> to quote:
>>>  On 3/21/2013 9:51 AM, Lou Berger wrote:
>>>  > Daniele,
>>>  ...
>>>  > On 3/21/2013 9:34 AM, Daniele Ceccarelli wrote:
>>>  >> Lou,
>>>  >>
>>>  >> OK. No changes to signaling re explicit indication of mapping
>>>  >> and/or TSG in the label.
>>>  >
>>>  > I think it would be a good idea to add a comment on this in the
>>>  > signaling document so that we don't have to revisit it 
>yet again...
>>>  >
>>>
>>>> If what you meant is the latter, could you provide some 
>>> proposed text to refine it.
>>>>
>>>
>>> I suggest that the authors propose some text on the list for 
>>> the WG to review.  Given that the explicit indication issue 
>>> was raised by one of the co-authors I suspect he can provide 
>>> text that ensures the issue is covered.  There's also some 
>>> related text already on page 7 of the framework draft.  If the 
>>> authors are unable to come up with a proposal, let me know and 
>>> I'll propose something to the list.
>>>
>>>> For point 2), the GPIDs have been grouped based on Table 15-8 in
>>>> G.709 (so it seems that some payload types in Table 15-8 are 
>>> missed), 
>>>> but I think you more like the 1:1 mapping between the GPID 
>>> defined in 
>>>> [SIGNALING] and Table 15-8.
>>>
>>> The only thing I'm asking for is to verify that it is possible 
>>> to unambiguously signal the G.709 defined payload types with 
>>> GMPLS. The authors are free to use any approach, e.g., 1:1 or 
>>> n:1+other signaled information.
>>>
>>>> We will check and list all the ungrouped GPIDs.
>>>>
>>>
>>> If you think it's possible to indicate all G.709 defined 
>>> payload types using the current "grouped" approach, that works 
>>> for me.  You just need to state such on the list.
>>>
>>> Perhaps it makes sense to just list how each PT in G.709 table 
>>> 15-8 is represented as a good sanity check. Such a list might 
>>> also be useful information to add to the draft.  Here's a 
>>> start at such a list.  I've flagged the results of a spot 
>>> check (i.e., I probably have missed
>>> something) of PTs for which I don't see an obvious mapping.
>>>
>>>    G.709
>>>   Payload
>>>    Type       G-PID
>>>   -------     -----
>>>    0x01        ???
>>>    0x02
>>>    0x03
>>>    0x04
>>>    0x05
>>>    0x06
>>>    0x07
>>>    0x08
>>>    0x09
>>>    0x0A
>>>    0x0B
>>>    0x0C
>>>    0x0D
>>>    0x0E
>>>    0x0F
>>>    0x10
>>>    0x11
>>>    0x12        ???
>>>    0x13        ???
>>>    0x14        ???
>>>    0x15        ???
>>>    0x16        ???
>>>    0x17        ???
>>>    0x18        ???
>>>    0x19        ???
>>>    0x1A
>>>    0x1B        ???
>>>    0x1C
>>>    0x20
>>>    0x21
>>>    0x55        Unused
>>>    0x66        Unused
>>>    0x80-0x8F   ???
>>>    0xFD        ?? (Is this needed?)
>>>    0xFE        ?? (Is this needed?)
>>>    0xFF        Unused
>>>
>>>
>>> Thanks,
>>> Lou
>>>
>>>>
>>>>
>>>>
>>>> Best Regards
>>>>
>>>> Fatai
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:[e-mail]]
>>>> Sent: Thursday, May 09, 2013 12:53 AM
>>>> To: CCAMP; [e-mail]; 
>>>> [e-mail]
>>>> Subject: Closing G.709 open issues
>>>>
>>>> Authors/WG,
>>>> 	I think all would like to wrap up the 709 documents 
>>> before Berlin.  
>>>> To do this we need to:
>>>> 1) Ensure all discussed points have been resolved
>>>> 2) Hold a 2nd LC to ensure consensus on all changes since 
>the 1st LC
>>>> 3) Capture the resolution of any comments made during 2.
>>>>
>>>> In reviewing the close to 200 mail messages on the documents 
>>> since the 
>>>> 1st LC was issued, I see only one a few points that are 
>>> still missing, 
>>>> and I'll cover these below.  On a side note, as an 
>>> experiment we'll be 
>>>> tracking these issue via the tools issues page:
>>>> http://tools.ietf.org/wg/ccamp/trac/report/1
>>>>
>>>> PLEASE reply to this message if you think there are other 
>>>> points/discussions that haven't been addressed in the 
>current set of 
>>>> documents. Once this thread is closed, the 2nd LC will be 
>initiated.
>>>>
>>>> The remaining items come from the tread with the final message 
>>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html
>>>> The message is from me in response to Daniele's summary of 
>>> next steps, 
>>>> and has the following unresolved actions:
>>>>
>>>> 1)  No explicit indication of TSG in the label [SIGNALING]
>>>>
>>>>   In signaling document section 6: Clarify related text to 
>>> unambiguous
>>>>   identify the relationship between label length and TSG. Possible
>>>>   target text to change:
>>>>    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.
>>>>
>>>> 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.
>>>>
>>>> 3) Identification of hexadecimal representation in G.709 vs
>>>>    decimal in GMPLS [INFO-MODEL]
>>>>
>>>>   The authors had previously stated the intent to just make 
>>> this clear
>>>>   in the signaling document.  I'd like to make an 
>alternate proposal:
>>>>   let's do the the obvious and have the documents simply use 
>>> the normal
>>>>   (IETF) convention of using a '0x' prefix anytime a 
>>> hexadecimal value
>>>>   is represented. I believe this means that only the 
>info-model draft
>>>>   needs to be updated.
>>>>
>>>> I believe that's the complete list. Again:
>>>> PLEASE reply to this message if you think there are other 
>>>> points/discussions that haven't been addressed in the 
>current set of 
>>>> documents.
>>>>
>>>> Much thanks,
>>>> Lou
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>> 
>> 
>> 
>