Re: [CCAMP] draft-ashok-ccamp-gmpls-ospf-g709 - comment on Multistage Muxing support

Rajan Rao <rrao@infinera.com> Tue, 09 November 2010 12:07 UTC

Return-Path: <rrao@infinera.com>
X-Original-To: ccamp@core3.amsl.com
Delivered-To: ccamp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73E233A68D9 for <ccamp@core3.amsl.com>; Tue, 9 Nov 2010 04:07:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.592
X-Spam-Level:
X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VG6HYzD9xfOB for <ccamp@core3.amsl.com>; Tue, 9 Nov 2010 04:07:22 -0800 (PST)
Received: from outgoing1.infinera.com (outgoing1.infinera.com [8.4.225.36]) by core3.amsl.com (Postfix) with ESMTP id 516F33A68DE for <ccamp@ietf.org>; Tue, 9 Nov 2010 04:07:22 -0800 (PST)
Received: from SV-EXDB1.infinera.com ([10.100.97.31]) by sv-exhub1.infinera.com ([10.100.97.36]) with mapi; Tue, 9 Nov 2010 04:06:49 -0800
From: Rajan Rao <rrao@infinera.com>
To: John E Drake <jdrake@juniper.net>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Date: Tue, 09 Nov 2010 04:06:47 -0800
Thread-Topic: [CCAMP] draft-ashok-ccamp-gmpls-ospf-g709 - comment on Multistage Muxing support
Thread-Index: Act/vyG/0JOf3Lb4SqmDAGQ+caolaQACoN1wAAjiYpAABfBOYA==
Message-ID: <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3F24BDB@SV-EXDB1.infinera.com>
References: <B5630A95D803744A81C51AD4040A6DAA02CF8B34@ESESSCMS0360.eemea.ericsson.se> <35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3F24BA8@SV-EXDB1.infinera.com> <5E893DB832F57341992548CDBB33316398C4348005@EMBX01-HQ.jnpr.net>
In-Reply-To: <5E893DB832F57341992548CDBB33316398C4348005@EMBX01-HQ.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/related; boundary="_005_35F57DFB766CCA4FBF4F3F680FA9D2CA6AC3F24BDBSVEXDB1infine_"; type="multipart/alternative"
MIME-Version: 1.0
Cc: "Dimitri.Papadimitriou@alcatel-lucent.be" <Dimitri.Papadimitriou@alcatel-lucent.be>, Yalin Wang <ywang@infinera.com>
Subject: Re: [CCAMP] draft-ashok-ccamp-gmpls-ospf-g709 - comment on Multistage Muxing support
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 09 Nov 2010 12:07:29 -0000

John,

We have an example covering link bundling case in section-7.3 of the draft

http://tools.ietf.org/html/draft-ashok-ccamp-gmpls-ospf-g709-02

The muxing hierarchy on each component link could be entirely different and is not known outside of the 2 nodes involved in bundling. This is no different from unbundled-Telink case.

Thanks
Rajan


From: John E Drake [mailto:jdrake@juniper.net]
Sent: Tuesday, November 09, 2010 5:14 PM
To: Rajan Rao; Daniele Ceccarelli; ccamp@ietf.org
Cc: Yalin Wang; Dimitri.Papadimitriou@alcatel-lucent.be
Subject: RE: [CCAMP] draft-ashok-ccamp-gmpls-ospf-g709 - comment on Multistage Muxing support

Hi,

This my understanding of how it should work, based upon what we have done to date with other technologies.   In the most complicated case we would have a bunch of ODUk plumbing (component links) between a pair of nodes.  Based upon the multiplexing capabilities of the various ODUk links, we would figure which ODUjs we supported and how many of each out we can switch.

We shouldn't have to advertise anything wrt the ODUk plumbing.  If we have to, then we won't be able to support link bundling, which I took to be a hard requirement.

Thanks,

John

Sent from my iPhone

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao
Sent: Monday, November 08, 2010 9:05 PM
To: Daniele Ceccarelli; ccamp@ietf.org
Cc: Yalin Wang
Subject: Re: [CCAMP] draft-ashok-ccamp-gmpls-ospf-g709 - comment on Multistage Muxing support

Danielle,

The path computing node shouldn't care where in the hierarchy a service is carried (e.g ODU0 LSP).  Link to link basis the hierarchy can & will vary (e.g. as OTN evolves).  The signaling decides what mux layer(s) to use to support the service locally.

What we advertise for a link is the ODUjs that a node can switch independent of what HO-ODU layer(s) it sits on.  This is all that is required for path computation.  The hierarchy information is local and is not flooded.

Thanks
Rajan

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: Tuesday, November 09, 2010 11:35 AM
To: ccamp@ietf.org
Subject: [CCAMP] draft-ashok-ccamp-gmpls-ospf-g709 - comment on Multistage Muxing support


Hi authors,

I don't understand how multistage muxing is addressed in the draft.
Section 7.2 states:

       Assume OTU3 interface that supports switching at line rate ODU3
       and lower rates - ODU0, ODU1, ODU2, ODU2e & ODUflex via
       multiplexing.
        [snip]
       ODUk Switching Capability Specific Information:
       +===============+================+===========================+
       |  Signal Type  | Bandwidth Type |  Available ODUs at Prio P |
       +===============+================+===========================+
       |    3 (ODU3)   | 0 (Max-Lsp-Bw) |            1              |
       +---------------+----------------+---------------------------+
       |    5 (ODU0)   | 0 (Max-Lsp-Bw) |            32             |
       +---------------+----------------+---------------------------+
       |    1 (ODU1)   | 0 (Max-Lsp-Bw  |            16             |
       +---------------+----------------+---------------------------+
       |    2 (ODU2)   | 0 (Max-Lsp-Bw) |            4              |
       +---------------+----------------+---------------------------+
       |    12 (ODU2e) | 0 (Max-Lsp-Bw) |            3              |
       +---------------+----------------+---------------------------+
If this is multistage muxing advertisement, you're implicitly assuming that Advertising ODU0, 1, 2, 2e and 3 *all* muxing combinations are supported:
- Single stage. E.g:
ODU0 into ODU1
ODU0 into ODU2
ODU0 into ODU3
ODU1 into ODU3
ODU2 into ODU3
and so on...

- Dual stage. E.g.
ODU0 into ODU1 into ODU2
ODU0 into ODU1 into ODU3
And so on...

- Triple stage e.g.
ODU0 into ODU1 into OUD2 into ODU3
And so on...

What if a node supports only a subset of those capabilities?

Thanks,
Daniele




DANIELE CECCARELLI
System & Technology - DU IP & Broadband

Via L.Calda, 5
Genova, Italy
Phone +390106002512
Mobile +393346725750
daniele.ceccarelli@ericsson.com
www.ericsson.com


[cid:image002.jpg@01CB8048.84E175C0]<http://www.ericsson.com/>

This Communication is Confidential. We only send and receive email on the basis of the term set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>