Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)

John E Drake <jdrake@juniper.net> Wed, 30 November 2011 20:01 UTC

Return-Path: <jdrake@juniper.net>
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 1A90921F84AF for <ccamp@ietfa.amsl.com>; Wed, 30 Nov 2011 12:01:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.557
X-Spam-Level:
X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Caa+jN1l9wSS for <ccamp@ietfa.amsl.com>; Wed, 30 Nov 2011 12:01:07 -0800 (PST)
Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF041F0C5C for <ccamp@ietf.org>; Wed, 30 Nov 2011 12:00:57 -0800 (PST)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTtaLb5A793ymtU0N0xkzkmH6Llt3vVjb@postini.com; Wed, 30 Nov 2011 12:00:57 PST
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 30 Nov 2011 11:59:51 -0800
From: John E Drake <jdrake@juniper.net>
To: Lou Berger <lberger@labn.net>
Date: Wed, 30 Nov 2011 11:59:49 -0800
Thread-Topic: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)
Thread-Index: Acyvfy3OHELEI/kxQNCYLrvojmo6JgAGOh8Q
Message-ID: <5E893DB832F57341992548CDBB333163A4B54CADAB@EMBX01-HQ.jnpr.net>
References: <B5630A95D803744A81C51AD4040A6DAA2293E672A9@ESESSCMS0360.eemea.ericsson.se> <4ED64A32.8060707@labn.net> <5E893DB832F57341992548CDBB333163A4B54CA99D@EMBX01-HQ.jnpr.net> <4ED65D2D.2040400@labn.net>
In-Reply-To: <4ED65D2D.2040400@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: CCAMP <ccamp@ietf.org>
Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)
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: Wed, 30 Nov 2011 20:01:08 -0000

Using Switching Capability to indicate link bandwidth seems ill-considered at best, especially since this information is carried in other fields, and as Daniele noted, it significantly overloads to intended meaning of Switching Capability.  It also is inconsistent with the usage of Switching Capability in SDH/SONET.

A more extensive quote from RFC4202 is the following, which seems clear enough to me:

"In the context of this document we say that a link is connected to a node by an interface.  In the context of GMPLS interfaces may have different switching capabilities.  For example an interface that connects a given link to a node may not be able to switch individual packets, but it may be able to switch channels within an SDH payload.  Interfaces at each end of a link need not have the same switching capabilities.  Interfaces on the same node need not have the same switching capabilities."

> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Wednesday, November 30, 2011 8:43 AM
> To: John E Drake
> Cc: Daniele Ceccarelli; CCAMP
> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2)
> 
> Great.  Care to substantiate your point?
> 
> On 11/30/2011 11:14 AM, John E Drake wrote:
> > I completely disagree.
> >
> >> -----Original Message-----
> >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
> Behalf
> >> Of Lou Berger
> >> Sent: Wednesday, November 30, 2011 7:22 AM
> >> To: Daniele Ceccarelli
> >> Cc: CCAMP
> >> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue
> 1/2)
> >>
> >> Hi Daniele,
> >> 	Since I raised the point, I guess I need to champion it!  (With
> >> chair
> >> hat off.)
> >>
> >> All,
> >>
> >> Daniele said:
> >>> WRT issue 1: the proposal was to indicate the bottom most ODUk of
> the
> >>> muxing hiearachy in the Switching Capability field of the ISCD.
> After
> >>> a quick talk with the other authors of the ID, the idea was to
> reject
> >>> the proposal as it would lead to an overloading of the meaning of
> the
> >>> Switching Capability field. (even if the definition of PSC1-2-3-4
> >>> already overloads the meaning of the switching capability field)
> >>
> >> This really goes to the interpretation of the intent of Switching
> >> Capability Types.  So we have a few definitions: 3471 says "the type
> of
> >> switching that should be performed", 4202 says  "describes switching
> >> capability of an interface." 3945 doesn't really define the term (it
> >> just references 4202), but does equate it with a "layer". While it
> >> allows for hierarchy within a "layer" it also says hierarchy occurs
> >> "between interface types".
> >>
> >> So I interpret Switching Capability Types to represent (a) different
> >> switching/technology layers and (b) different levels of hierarchy --
> >> even within a layer.  I think (a) is identifiable in the definition
> of
> >> the original GMPLS supported technologies (i.e., PSC, L2SC, TDM LSC,
> >> and
> >> FSC), and (b) is identifiable in the original types plus the
> definition
> >> of PSC-1 through PSC-4.
> >>
> >> So how does this apply to our current OTN work?
> >>
> >> To me, the first question to ask relates to (a), and is should each
> >> ODUk
> >> be modeled as a separate layer?
> >>
> >> I know this has been a much debated point, and it seems to me that
> they
> >> are, but more for the perspective of switching layers than
> technology
> >> layers (i.e., they are clearly the same technology but are different
> >> granularity of swicthing.) So this is a yes for me.
> >>
> >> I think the second question to ask relates to (b), and is does each
> >> ODUk
> >> represent a different level of hierarchy?
> >>
> >> I see this as simply yes, and no different than what has been done
> more
> >> recently with Ethernet or, even if we do continue to model OTN as a
> >> single layer, no different than PSC-1 -> PSC-4.
> >>
> >> There's also a minor processing efficiency gained by this approach
> for
> >> nodes that support a smaller set of ODUks than are advertised within
> an
> >> IGP.
> >>
> >> Based on all this, I believe different ODUk's should use different
> >> Switching Types.  In particular, I'm proposing:
> >> (1) that either the framework or info documents identify that
> >>     a per-OTUk Switching Capability Types will be used to support
> >>     G.709v3.
> >> (2) that draft-ietf-ccamp-gmpls-ospf-g709v3 define a different
> >>     Switching Cap field value for each ODUk, and that it state
> >>     that the value corresponding to the signal type identified in
> >>     the #stages=0 of the ISCP be set.  (Without any other changes
> >>     to the current definition of ISCD.)
> >> (3) that draft-ietf-ccamp-gmpls-signaling-g709v3 be updated to
> >>     match above.
> >>
> >> To keep thinks generic, we probably should use TDM-1 through TDM-n
> as
> >> the new Switching Capability Types, but this is a secondary
> discussion.
> >>
> >> Comments?
> >>
> >> Lou
> >>
> >> PS While the above is an important change, it doesn't significantly
> >> impact encoding and won't take much text to make the actual change,
> so
> >> this is a discussion that can continue until Paris if we really need
> a
> >> face to face to resolve the discussion.
> >>
> >> On 11/23/2011 1:18 PM, Daniele Ceccarelli wrote:
> >>> Hi CCAMP,
> >>>
> >>>
> >>>
> >>> During the OTN OSPF draft presentation at the IETF meeting in
> Taipei
> >> two
> >>> comments were raised with respect to the following issues:
> >>>
> >>>
> >>>
> >>> - Issue 1: Using different switching caps for each ODU type
> >>>
> >>> - Issue 2: Type 2 (unres bandwidth for variable containers) and
> Type
> >> 3
> >>> (MAX LSP bandwidth foe variable containers always used in tandem?
> >>>
> >>>
> >>>
> >>> WRT issue 1: the proposal was to indicate the bottom most ODUk of
> the
> >>> muxing hiearachy in the Switching Capability field of the ISCD.
> After
> >> a
> >>> quick talk with the other authors of the ID, the idea was to reject
> >> the
> >>> proposal as it would lead to an overloading of the meaning of the
> >>> Switching Capability field. (even if the definition of PSC1-2-3-4
> >>> already overloads the meaning of the switching capability field)
> >>>
> >>>
> >>>
> >>> WRT issue 2: it is analyzed in section 5.3 of the draft (version -
> >> 00).
> >>> I'm copying it below for your convenience
> >>>
> >>>
> >>>
> >>>    In this example the advertisement of an ODUflex->ODU3 hierarchy
> is
> >>>
> >>>    shown.  In case of ODUflex advertisement the MAX LSP bandwidth
> >> needs
> >>>
> >>>    to be advertised but in some cases also information about the
> >>>
> >>>    Unreserved bandwidth could be useful.  The amount of Unreserved
> >>>
> >>>    bandwidth does not give a clear indication of how many ODUflex
> LSP
> >>>
> >>>    can be set up either at the MAX LSP Bandwidth or at different
> >> rates,
> >>>
> >>>    as it gives no information about the spatial allocation of the
> >> free
> >>>
> >>>    TSs.
> >>>
> >>>
> >>>
> >>>    An indication of the amount of Unreserved bandwidth could be
> >> useful
> >>>
> >>>    during the path computation process, as shown in the following
> >>>
> >>>    example.  Supposing there are two TE-links (A and B) with MAX
> LSP
> >>>
> >>>    Bandwidth equal to 10 Gbps each.  In case 50Gbps of Unreserved
> >>>
> >>>    Bandwidth are available on Link A, 10Gbps on Link B and 3
> ODUflex
> >>>
> >>>    LSPs of 10 GBps each, have to be restored, for sure only one can
> >> be
> >>>
> >>>    restored along Link B and it is probable (but not sure) that two
> >> of
> >>>
> >>>    them can be restored along Link A.
> >>>
> >>>
> >>>
> >>> Early proposal was to have, in the case of variable containers
> >>> advertisements (i.e. ODUflex), the MAX LSP bandwidth TLV (Type 3)
> as
> >> a
> >>> mandatory piece of information and the Unreserved bandiwdth TLV
> (Type
> >> 2)
> >>> as an optional piece of information.
> >>>
> >>> The comment received is that optional information can lead to
> >>> interworking issues and the counter proposal was to have both
> pieces
> >> of
> >>> information as mandatory and, as a consequence, merge the two TLVs
> >> into
> >>> a single one.
> >>>
> >>>
> >>>
> >>> We'd like to hear the opinion of the WG on both issues before
> >> proceeding
> >>> with any modification to the document.
> >>>
> >>>
> >>>
> >>> 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
> >>>
> >>>
> >>>
> >>> <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>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >
> >
> >
> >