Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues)

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

It should be blindingly obvious to the informed reader that in the context of [G709-2012], the values of 4 and 16 indicate a TS granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps.

Yours Irrespectively,

John

> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Tuesday, May 21, 2013 5:38 PM
> To: John E Drake
> Cc: Fatai Zhang; [e-mail];
> CCAMP; [e-mail]
> Subject: RE: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709
> open issues)
> 
> John,
> 
> Great. It seems we agree that it shouldn't have been necessary to
> discuss this point so many times, and that the additional text doesn't
> change the field definition. It is informative narrative after all.
> 
> Now that said, can you live with the revised "overly precise" text so
> that we can move forward (and ensure we're not back here again)?
> 
> Lou
> 
> On May 21, 2013 4:23:37 PM John E Drake <[e-mail]> wrote:
> > Lou,
> >
> > The question that has always been is whether signaling needed to
> > include an explicit TSG filed and the answer has always been no
> > because it can be derived from other fields.  The text I proposed
> > makes that derivation explicit and unambiguous.  The additional text
> > you are proposing adds neither clarity nor information.
> >
> > Yours Irrespectively,
> >
> > John
> >
> > > -----Original Message-----
> > > From: Lou Berger [mailto:[e-mail]]
> > > Sent: Tuesday, May 21, 2013 5:37 AM
> > > To: John E Drake
> > > Cc: Fatai Zhang;
> > > [e-mail];
> > > CCAMP; [e-mail]
> > > Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing
> > > G.709 open issues) John, Really?  You're joking right?
> > > As I said to Fatai:
> > >    My feeling is that there have been too many "surprises" on the
> 709
> > >    documents in areas that I thought were ... resolved by past
> > >    discussions.  At this point, as co-chair and Document shepherd,
> I
> > >    want to ensure that any open point on the documents are
> > >    unambiguously closed and that past discussions (i.e., points of
> > >    consensus) are 100% captured, so that we can smoothly move
> through
> > >    the planned second LC and publication request.
> > > The particular point of the ambiguity/implicit nature of
> determining
> > > TSG from length has been brought up at least three times.  (Note,
> by
> > > others in the WG -- this is not my concern.) Each time the
> consensus
> > > from the discussion is to leave as is, but no or only minimal
> > > changes were made to the document.  I opened the trac ticket to
> > > ensure that the consensus was documented in the draft and that we
> > > don't have to yet again revisit this topic -- which *is* my
> concern.
> > > So, the revised text addresses your concern of not needing to
> > > redefine the field for new 709 rate or TSGs, and it is sufficiently
> > > precise so that non should misinterpret the current "implicit"
> > > specification of TSG.
> > > Can we/you accept the revised "overly precise" text and move
> forward?
> > > Lou
> > > On 5/20/2013 10:30 PM, John E Drake wrote:
> > > > What is behind your preoccupation with enumerating all possible
> > > combinations of length & TSG?  Do you have trouble with arithmetic?
> > > >
> > > > Sent from my iPhone
> > > >
> > > > On May 20, 2013, at 1:42 PM, "Lou Berger" <[e-mail]>
> wrote:
> > > >
> > > >>
> > > >>
> > > >> On 5/20/2013 3:18 PM, John E Drake wrote:
> > > >>> I think that's a big mistake(tm).  If a new rate or TSG is
> > > >>> introduced the RFC would need to be updated even though the
> > > encoding
> > > >>> does not require it.
> > > >>
> > > >> Well that's easily addressed, via something like:
> > > >>
> > > >> Length (12 bits): indicates the number of bits of the Bit Map
> > > >> field, i.e., the number of TS in the HO ODUk link.  The TS
> > > >> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing the
> > > >> HO ODUk link's rate by the value of the Length field.  In the
> > > >> context of [G709-2012], the values of 4 and 16 indicate a TS
> > > >> granularity of 2.5Gps, and the values 2, 8, 32 and 80 indicate a
> > > >> TS granularity of
> > > 1.25Gps.
> > > >>
> > > >> Lou
> > > >>
> > > >>> Sent from my iPhone
> > > >>>
> > > >>> On May 20, 2013, at 2:43 PM, "Lou Berger" <[e-mail]>
> wrote:
> > > >>>
> > > >>>> John,
> > > >>>> There's still some ambiguity here.  How about:
> > > >>>> On 5/20/2013 9:15 AM, John E Drake wrote:
> > > >>>>> Length (12 bits): indicates the number of bits of the Bit Map
> > > >>>>> field, i.e., the number of TS in the HO ODUk link.  The TS
> > > >>>>> granularity, 1.25Gbps or 2.5Gbps, may be derived by dividing
> > > >>>>> the HO ODUk link's rate by the value of the Length field.
> > > >>>>
> > > >>>>
> > > >>>> Replace:
> > > >>>>> For example, for an HO ODU2
> > > >>>>> link, whose link rate is 10Gbps, the value of the Length
> field
> > > >>>>> will be either 4 or 8 and the TS granularity will be either
> > > >>>>> 2.5Gbps or 1.25Gbps, respectively.
> > > >>>> With:
> > > >>>>
> > > >>>>  The values of 4 and 16 indicate a TS granularity of 2.5Gps,
> > > >>>> while the values 2, 8, 32 and 80 indicate a TS granularity of
> 1.25Gps.
> > > >>>>
> > > >>>> Lou
> > > >>>>
> > > >>>>
> > > >>>>> Irrespectively Yours,
> > > >>>>>
> > > >>>>> John
> > > >>>>>
> > > >>>>>
> > > >>>>>> -----Original Message-----
> > > >>>>>> From: Lou Berger [mailto:[e-mail]]
> > > >>>>>> Sent: Friday, May 17, 2013 1:33 PM
> > > >>>>>> To: John E Drake
> > > >>>>>> Cc: Fatai Zhang;
> > > >>>>>> [e-mail];
> > > >>>>>> CCAMP; draft-ietf-ccamp-gmpls-signaling-
> [e-mail]
> > > >>>>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was:
> > > Closing
> > > >>>>>> G.709 open issues)
> > > >>>>>>
> > > >>>>>> John,
> > > >>>>>>   I guess you haven't been paying attention!  The rewrite
> > > >>>>>> originated from Daniele, was tweaked by me and then fixed by
> > > Fatai.
> > > >>>>>>
> > > >>>>>> Do you have an alternate proposal to address issue#48?
> > > >>>>>> Issue #48="In signaling document section 6: Clarify related
> > > >>>>>> text [i.e., the OLD text] to unambiguously identify the
> > > >>>>>> relationship between label length and TSG."
> > > >>>>>>
> > > >>>>>> Thanks,
> > > >>>>>> Lou
> > > >>>>>>
> > > >>>>>> On 5/17/2013 1:15 PM, John E Drake wrote:
> > > >>>>>>> Lou,
> > > >>>>>>>
> > > >>>>>>> I think the original text is fine and your attempted
> > > >>>>>>> re-write
> > > >>>>>> completely mangled its meaning.  The label is a bit vector
> > > >>>>>> whose length is equal to the ODUk rate / TSG.
> > > >>>>>>>
> > > >>>>>>> Irrespectively Yours,
> > > >>>>>>>
> > > >>>>>>> John
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>> -----Original Message-----
> > > >>>>>>>> From: [e-mail]
> > > >>>>>>>> [mailto:[e-mail]]
> > > On
> > > >>>>>>>> Behalf Of Lou Berger
> > > >>>>>>>> Sent: Friday, May 17, 2013 9:17 AM
> > > >>>>>>>> To: Fatai Zhang
> > > >>>>>>>> Cc: [e-mail];
> > > CCAMP;
> > > >>>>>>>> draft- [e-mail]
> > > >>>>>>>> Subject: [CCAMP] Confirming plan for Issue #48: (Was:
> > > >>>>>>>> Closing
> > > >>>>>>>> G.709 open issues)
> > > >>>>>>>>
> > > >>>>>>>> Authors/WG,
> > > >>>>>>>>   From the mail on the list it seems to me that we've
> > > >>>>>>>> reached
> > > >>>>>> closure
> > > >>>>>>>> on Issue #48: "Document no explicit indication of TSG in
> > > >>>>>>>> the
> > > label"
> > > >>>>>>>> (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48).  I'd
> > > like
> > > >>>>>>>> to confirm my reading.
> > > >>>>>>>>
> > > >>>>>>>> As I read the list, this issue will be resolved by making
> > > >>>>>>>> the following change to draft-ietf-ccamp-gmpls-signaling-
> g709v3.
> > > >>>>>>>>
> > > >>>>>>>> OLD
> > > >>>>>>>> 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.
> > > >>>>>>>>
> > > >>>>>>>> NEW
> > > >>>>>>>> Please note that the TS granularity of an HO ODUk can be
> > > >>>>>>>> inferred from the length of the label. The values of 4 and
> > > >>>>>>>> 16 indicate a TS granularity of 2.5Gps, while the values
> 2,
> > > >>>>>>>> 8, 32 and 80 indicate a
> > > >>>>>> TS
> > > >>>>>>>> granularity of 1.25Gps.
> > > >>>>>>>>
> > > >>>>>>>> Please speak up if you disagree with this resolution.
> > > >>>>>>>>
> > > >>>>>>>> Thanks,
> > > >>>>>>>> Lou
> > > >>>>>>>>
> > > >>>>>>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote:
> > > >>>>>>>>> For point 1), "1" should be dropped and "7" should be
> > > >>>>>>>>> corrected to
> > > >>>>>>>> "8" in your proposed text.
> > > >>>>>>>>
> > > >>>>>>>> _______________________________________________
> > > >>>>>>>> CCAMP mailing list
> > > >>>>>>>> [e-mail]
> > > >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
> 
>