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

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

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
>