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

[Lou Berger <[e-mail]>]

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
>>
>