Re: [CCAMP] [RTG-DIR] R: RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt

["Joel M. Halpern" <[e-mail]>]

The proposed alternative text would suffice, although personally I would 
just remove the two sections.

Yours,
Joel

On 9/27/13 3:00 PM, Lou Berger wrote:
> Joel,
> 	Does the proposed altnerate text address your comment (assuming the
> author's want to keep the sections)?  If not, can you suggest changes?
>
> Thanks,
> Lou
>
> On 09/27/2013 02:30 PM, Joel M. Halpern wrote:
>> Lou, thanks for stepping in.
>> With your explanation I can live with the LSP text as it is.
>>
>> I look forward to further conversation on the other point.
>>
>> Yours,
>> Joel
>>
>> On 9/27/13 1:37 PM, Lou Berger wrote:
>>> Joel/Authors,
>>>
>>> I thought I might jump in on two points:
>>>
>>>
>>> On 9/26/2013 4:50 AM, BELOTTI, SERGIO (SERGIO) wrote:
>>>> Hello Joel,
>>>>
>>>> thanks for your comments.
>>>> Below in line our reply, marked "authors".
>>>>
>>>
>>> ...
>>>
>>>>        Given that this document is about mapping to G.709, it is
>>>> unclear what is intended by the usage of "LSP".  My guess is that it
>>>> is intended to mean Label Switch Paths set up by GMPLS to carry
>>>> OTU/UDU elements.
>>>> It should be stated explicitly.
>>>>
>>>> Authors> We can specify this as you suggest even if we considered not
>>>> necessary to specify the usage of LSP in relation to data plane
>>>> specific. Encoding type should cope with this issue.
>>>>
>>>
>>> Joel,
>>>
>>> I suspect that the usage of LSP in the absence of the MPLS data plane is
>>> what's causing confusion here.  Is this correct?
>>>
>>> If so, I think GMPLS referencing controlled data paths (circuits) by the
>>> common name of Label Switched Path (LSP) is sufficiently established
>>> that this document doesn't need to revisit it.  In any case, the
>>> document already provides context:
>>>
>>>      GMPLS routing and signaling, as defined by [RFC4203], [RFC5307],
>>>      [RFC3473] and [RFC4328], provides the mechanisms for basic GMPLS
>>>      control of OTN networks based on the 2001 revision of the G.709
>>>      specification.
>>> and
>>>      Background information and a framework for the GMPLS protocol
>>>      extensions need to support [G.709-2012] is provided in [OTN-FWK].
>>>
>>> [OTN-FWK] has the often repeated concept:
>>>
>>>      GMPLS extends Multi-Protocol Label Switching (MPLS) to encompass time
>>>      division multiplexing (TDM) networks (e.g., Synchronous Optical
>>>      NETwork (SONET)/ Synchronous Digital Hierarchy (SDH), Plesiochronous
>>>      Digital Hierarchy (PDH), and G.709 sub-lambda), lambda switching
>>>      optical networks, and spatial switching (e.g., incoming port or fiber
>>>      to outgoing port or fiber).  The GMPLS architecture is provided in
>>>      [RFC3945],
>>>
>>> If this doesn't cover the comment, can you elaborate on what you want
>>> explicitly stated?
>>>
>>>> ...
>>>>
>>>>        Section 8 on Maximum LSP Bandwdith seems to be objecting to too
>>>> much information leading to a "waste of bits".  While possibly of
>>>> interest to the WG, that does not seem to fit a gap analysis.
>>>>        Similarly, section 10 on Priority Support reads as
>>>> implementation advice rather than a gap needing protocol changes.
>>>>
>>>> Authors> The basic scope of the draft is to underline gaps, and even
>>>> if what described in Ch.8 and 10, do not prevent routing to work , it
>>>> is suggested here an requirement for optimization based on OTN
>>>> requirements (e.g. no need to advertise fixed ODU container Max LSP
>>>> BW since implicit in the signal type.)
>>>>
>>>
>>> Authors,
>>>      I completely agree with Joel on this point, furthermore sections
>>> 10 and
>>> 8 overlap.  One approach to address his point would be to simply drop
>>> both sections.  An alternative is try to rephrase them to address Joel's
>>> points.  I've taken a pass at the latter below, but won't object if the
>>> authors prefer the former.
>>>
>>> Here's a suggested wording change if you choose to keep the sections:
>>> OLD:
>>>      8. Maximum LSP Bandwidth
>>>
>>>      Maximum LSP bandwidth is currently advertised in the common part of
>>>      the ISCD and advertised per priority, while in OTN networks it is
>>>      only required for ODUflex advertising.  This leads to a significant
>>>      waste of bits inside each LSA.
>>> and
>>>
>>> NEW
>>> 8. Maximum LSP Bandwidth
>>>
>>>      Maximum LSP bandwidth is currently advertised per priority in the
>>>      common part of the ISCD.  Section 5 reviews some of the implications
>>>      of advertising OTN network information using  ISCDs, and
>>>      identifies the need for a more optimized solution.  While strictly
>>>      not required, such an optimization effort should also consider the
>>>      optimization of the per priority maximum LSP bandwidth advertisement
>>>      of both fixed and variable ODU types.
>>>
>>> OLD
>>>      10. Priority Support
>>>
>>>      [RFC4202] defines 8 priorities for resource availability and usage.
>>>      All of them have to be advertised independently on the number of
>>>      priorities supported by the implementation.  Considering that the
>>>      advertisement of all the different supported signal types will
>>>      originate large LSAs, it is advised to advertise only the information
>>>      related to the really supported priorities.
>>> NEW
>>>      10. Priority Support
>>>
>>>      [RFC4202] defines 8 priorities for resource availability and usage.
>>>      As defined, each is advertised independent of the number of
>>>      priorities supported by a network.  As is the case in Section 8,
>>>      addressing any inefficiency with such advertisements is not required
>>>      to support OTN networks.  But any such inefficiency should also be
>>>      considered as part of the optimization effort identified in Section
>>>      5.
>>>
>>> Also please replace "Bw" with "Bandwidth" in the document.
>>>
>>> Lou
>>>
>>
>
>