Re: [CCAMP] RFC 7138 Example (Figure 7)

"Gruman, Fred" <> Mon, 24 March 2014 22:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D86641A02A2 for <>; Mon, 24 Mar 2014 15:18:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GIleXtMB3mpt for <>; Mon, 24 Mar 2014 15:18:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6C97A1A02AE for <>; Mon, 24 Mar 2014 15:18:05 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.97,723,1389765600"; d="scan'208";a="47896187"
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 24 Mar 2014 17:18:05 -0500
Received: from ([]) by ([]) with mapi id 14.02.0347.000; Mon, 24 Mar 2014 17:17:41 -0500
From: "Gruman, Fred" <>
To: Rajan Rao <>, "" <>
Thread-Topic: RFC 7138 Example (Figure 7)
Thread-Index: AQHPP61GPlH4vYkTSUO40uzaWSDIHprwqKQAgACHTYD//63bQA==
Date: Mon, 24 Mar 2014 22:18:03 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--58.134900-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [CCAMP] RFC 7138 Example (Figure 7)
X-Mailman-Version: 2.1.15
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: Mon, 24 Mar 2014 22:18:08 -0000

Hi Rajan,

Ok, I understand.  I didn't realize the ODU2 setup at T2 was creating a second ODU3.  But given this, I understand the example.


-----Original Message-----
From: Rajan Rao [] 
Sent: Monday, March 24, 2014 5:10 PM
To: Gruman, Fred;
Subject: RE: RFC 7138 Example (Figure 7)


This be because the mux hierarchy used in the example is ODU1->ODU2->ODU3->ODU4.  Meaning,  ODU2 requires higher-order ODU3. So, the second ODU3 is taken up to support this ODU2-LSP.  Hence only 10G as MaxLSP BW.


-----Original Message-----
From: CCAMP [] On Behalf Of Gruman, Fred
Sent: Monday, March 24, 2014 12:13 PM
Subject: [CCAMP] RFC 7138 Example (Figure 7)

Hi Daniele,

I had a question about the example in Section 5, Figure 7.

Section 5 is a time series about advertisement on a OTU4 link.
 - t=0.  No LSP.  Figure 5.  OK.
 - t=T1.  ODU3 LSP added.  Figure 6.  OK.
 - t=T2.  ODU2 LSP added.  Figure 7.  <error?>

An ODU4 has 80 TS.  To multiplex an ODU3 requires 31 TS and an ODU2 requires 8 TS.  So at t=T2, I have an ODU3 and an ODU2 = 39TS total.  This leaves 41 TS remaining which is more than enough to carry an additional ODU3.

Thus, figure 7 should show priority 2-7 = 40 Gbps.

Is this correct?

(Maybe the example should have the second LSP rate=ODU3 instead of ODU2 and then Figure 7 would be correct).

Best Regards,

-----Original Message-----
From: CCAMP [] On Behalf Of
Sent: Friday, March 14, 2014 12:45 PM
Subject: [CCAMP] RFC 7138 on Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks

A new Request for Comments is now available in online RFC libraries.

        RFC 7138

        Title:      Traffic Engineering Extensions to OSPF 
                    for GMPLS Control of Evolving G.709 
                    Optical Transport Networks 
        Author:     D. Ceccarelli, Ed.,
                    F. Zhang, S. Belotti,
                    R. Rao, J. Drake
        Status:     Standards Track
        Stream:     IETF
        Date:       March 2014
        Pages:      36
        Characters: 77038
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-gmpls-ospf-g709v3-13.txt


This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support GMPLS control of Optical Transport Networks (OTNs) specified in ITU-T Recommendation G.709 as published in 2012.  It extends mechanisms defined in RFC 4203.

This document is a product of the Common Control and Measurement Plane Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.  Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see

For searching the RFC series, see For downloading RFCs, see

Requests for special distribution should be addressed to either the author of the RFC in question, or to  Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

CCAMP mailing list

CCAMP mailing list