Re: [CCAMP] Closing G.709 open issues

[Lou Berger <[e-mail]>]

On 5/9/2013 9:41 PM, Fatai Zhang wrote:
> Hi Lou,
> 
> For point 1), "1" should be dropped and "7" should be corrected to "8" in your proposed text. 

Great.

> 
> I hesitate to make a decision on either approach, I would like to defer to the WG consensus.
> 

I believe we already have a consensus position.  The question in my mail
was do we need to revisit it.  I take your response as a no. (thank you!)

> 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):
> 

I suggest going through the full PT list and identifying them in the
table (as I started in my last message) so that there is no confusion in
implementations.

In the list below it looks like you have moved away from the 'grouped
G-PID' approach.  Is there a reason for this change?

Refer to
http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml
in subsequent comments.

>     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

Do you really need 3 G-PID types for an ODU (I thought TSG was already
covered)?

>    61(TBA)     PCS                    G.709 ODUk (k=0)
>    62(TBA)     FC-1200                G.709 ODUk (k=2e)
Why not us existing G-PID 58?

>    63(TBA)     eOPU2                 G.709 ODUk (k=2)

>    64(TBA)     STM-1                  G.709 ODUk (k=0)
>    65(TBA)     STM-4                  G.709 ODUk (k=0)
Why not us existing G-PID 34?

>    66(TBA)     FC-100                 G.709 ODUk (k=0)
>    67(TBA)     FC-200                 G.709 ODUk (k=1)
>    68(TBA)     FC-400                 G.709 ODUflex
>    69(TBA)     FC-800                 G.709 ODUflex
Why not us existing G-PID 58?

>    70(TBA)     IB SDR                 G.709 ODUflex
>    71(TBA)     IB DDR                 G.709 ODUflex
>    72(TBA)     IB QDR                 G.709 ODUflex
Can these be one value with rate implying SDR/DDR/QDR?

>    73(TBA)     SDIa                   G.709 ODUk (k=0)
>    74(TBA)     SDIb                   G.709 ODUk (k=1)
>    75(TBA)     SDIc                   G.709 ODUk (k=1)
>    76(TBA)     SDId                   G.709 ODUflex
>    77(TBA)     SDIe                   G.709 ODUflex

Can these be one value with rate implying a-e?

>    78(TBA)     SB/ESCON              G.709 ODUk (k=0)
Why not us existing G-PID 56?

>    79(TBA)     DVB_ASI                G.709 ODUk (k=0)
> 
> 
> 
> 

Thanks,
Lou

> 
> Best Regards
> 
> Fatai
> 
> 
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]] 
> Sent: Friday, May 10, 2013 1:21 AM
> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
> 
> 
> 
>