Re: [CCAMP] Closing G.709 open issues

[Lou Berger <[e-mail]>]

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