Re: [CCAMP] Closing G.709 open issues

[Fatai Zhang <[e-mail]>]

Hi Lou,

For point 1), "1" should be dropped and "7" should be corrected to "8" in your proposed text. 

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

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                    G.709 ODUk (k=0)
   62(TBA)     FC-1200                G.709 ODUk (k=2e)
   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)
   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
   70(TBA)     IB SDR                 G.709 ODUflex
   71(TBA)     IB DDR                 G.709 ODUflex
   72(TBA)     IB QDR                 G.709 ODUflex
   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
   78(TBA)     SB/ESCON              G.709 ODUk (k=0)
   79(TBA)     DVB_ASI                G.709 ODUk (k=0)





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