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

[Fatai Zhang <[e-mail]>]

Lou and John,

Thanks. 

Happy to see that you both provided the same proposed text. 




Best Regards

Fatai


-----Original Message-----
From: John E Drake [mailto:[e-mail]] 
Sent: Thursday, May 23, 2013 10:10 AM
To: Fatai Zhang; Lou Berger
Cc: CCAMP
Subject: RE: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues)

Fatai,

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.

Yours Irrespectively,

John


> -----Original Message-----
> From: Fatai Zhang [mailto:[e-mail]]
> Sent: Wednesday, May 22, 2013 5:55 PM
> To: John E Drake; Lou Berger
> Cc: CCAMP
> Subject: RE: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709
> open issues)
> 
> Hi Lou and John,
> 
> Thanks for your discussion on providing the proposed text.
> 
> However, I am lost by the discussion.
> 
> What is the final proposed text? I hope someone can finalize it.
> 
> I think it is time to conclude the discussion on this point (the
> original point 1).
> 
> 
> 
> Best Regards
> 
> Fatai
> 
> 
> -----Original Message-----
> From: John E Drake [mailto:[e-mail]]
> Sent: Thursday, May 23, 2013 2:01 AM
> To: Lou Berger
> Cc: Fatai Zhang; CCAMP
> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709
> open issues)
> 
> Bummer
> 
> Sent from my iPhone
> 
> On May 22, 2013, at 10:45 AM, "Lou Berger" <[e-mail]> wrote:
> 
> > I'm empathetic with the addition, but suspect it's best not to put
> the
> > first 10 words in the draft...
> >
> > Lou
> >
> > On 5/21/2013 8:45 PM, John E Drake wrote:
> >> 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
> >
>