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

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.

Fred

-----Original Message-----
From: Rajan Rao [mailto:rrao@infinera.com] 
Sent: Monday, March 24, 2014 5:10 PM
To: Gruman, Fred; daniele.ceccarelli@ericsson.com
Cc: ccamp@ietf.org
Subject: RE: RFC 7138 Example (Figure 7)

Fred,

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.

Thx
Rajan 

-----Original Message-----
From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Gruman, Fred
Sent: Monday, March 24, 2014 12:13 PM
To: daniele.ceccarelli@ericsson.com
Cc: ccamp@ietf.org
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,
Fred

-----Original Message-----
From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org
Sent: Friday, March 14, 2014 12:45 PM
To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org
Cc: drafts-update-ref@iana.org; ccamp@ietf.org; rfc-editor@rfc-editor.org
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
        Mailbox:    daniele.ceccarelli@ericsson.com, 
                    zhangfatai@huawei.com, 
                    sergio.belotti@alcatel-lucent.com,
                    rrao@infinera.com, 
                    jdrake@juniper.net
        Pages:      36
        Characters: 77038
        Updates/Obsoletes/SeeAlso:   None

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

        URL:        http://www.rfc-editor.org/rfc/rfc7138.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
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org.  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@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp