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

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 27 September 2013 19:26 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC0821F9F8F; Fri, 27 Sep 2013 12:26:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.432
X-Spam-Level:
X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhvauI1Ay+dc; Fri, 27 Sep 2013 12:26:15 -0700 (PDT)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 4784121F9E00; Fri, 27 Sep 2013 12:26:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 32307122669; Fri, 27 Sep 2013 12:26:13 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 459A4122668; Fri, 27 Sep 2013 12:26:11 -0700 (PDT)
Message-ID: <5245DBD4.8000301@joelhalpern.com>
Date: Fri, 27 Sep 2013 15:26:12 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Lou Berger <lberger@labn.net>
References: <522DBBBC.7050103@joelhalpern.com> <B9FEE68CE3A78C41A2B3C67549A96F482463FDB4@FR711WXCHMBA05.zeu.alcatel-lucent.com> <5245C274.6090707@labn.net> <5245CED2.5020400@joelhalpern.com> <5245D5D3.2070303@labn.net>
In-Reply-To: <5245D5D3.2070303@labn.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, CCAMP WG <ccamp@ietf.org>, "draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org" <draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Subject: Re: [CCAMP] [RTG-DIR] R: RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Sep 2013 19:26:22 -0000

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