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

Lou Berger <> Fri, 27 September 2013 17:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B9D021E8100 for <>; Fri, 27 Sep 2013 10:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.889
X-Spam-Status: No, score=-101.889 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ARWOC9dNrX8y for <>; Fri, 27 Sep 2013 10:38:28 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 1E26E21F9CDF for <>; Fri, 27 Sep 2013 10:38:24 -0700 (PDT)
Received: (qmail 10745 invoked by uid 0); 27 Sep 2013 17:37:57 -0000
Received: from unknown (HELO ( by with SMTP; 27 Sep 2013 17:37:57 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=p3+STk2vAr9incfOEdaLPDQTj5TyKcJk8B1qKCcRVYA=; b=NFYnZrpP+udxswD8Gq71PrSLLPSJWdo6gZ2nBx+Wtd2IibGahswqYHUO5Swj8JukZd8zfMksEGQoVGmev5gUD1IbzHCdjq0dTSksy1A4K1nkq4TsylcehxdF9z8GkmfL;
Received: from ([]:50241 helo=[]) by with esmtpa (Exim 4.80) (envelope-from <>) id 1VPbzJ-00068M-Mj; Fri, 27 Sep 2013 11:37:57 -0600
Message-ID: <>
Date: Fri, 27 Sep 2013 13:37:56 -0400
From: Lou Berger <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "BELOTTI, SERGIO (SERGIO)" <>, "Joel M. Halpern" <>, "" <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Identified-User: {} {sentby:smtp auth authed with}
Cc: "" <>, CCAMP WG <>, "" <>
Subject: Re: [CCAMP] [RTG-DIR] R: RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 Sep 2013 17:38:33 -0000


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. 


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

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

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

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.

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

Also please replace "Bw" with "Bandwidth" in the document.