Re: [CCAMP] Closing G.709 open issues

[John E Drake <[e-mail]>]

Can we please just go with 1?

Irrespectively Yours,

John

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Daniele Ceccarelli
> Sent: Thursday, May 09, 2013 11:58 PM
> To: Lou Berger
> Cc: [e-mail]; CCAMP;
> [e-mail]
> Subject: Re: [CCAMP] Closing G.709 open issues
> 
>  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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp