Re: [CCAMP] Closing G.709 open issues

[Lou Berger <[e-mail]>]

Daniele,

Most excellent!

Once the three open items are addressed (by 2 updated drafts) we'll be
ready for the second LC.

Lou

On 5/10/2013 2:57 AM, Daniele Ceccarelli wrote:
>  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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
> 
> 
>