Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-14.txt

["PELOSO, PIERRE (PIERRE)" <[e-mail]>]

Hi Greg and Young,

Thanks for your answers.
 So just to get things right, in case there is inside a WSON a node corresponding to the attached  picture. 
[Comment ON] Its internal structure is one of the most basic ones and  it relies on optical splitters (left-side) and Wavelength Selective  Switches (right-side).  The picture defines N as being the  number of neighbouring nodes and M as being the number of physical  pools of OEO. [Comment OFF]
 This networks supports at least two different types of  optical signal (given bit-rate and modulation format), this implies  at least two different types of OEO resources mentionned here OEO type 1 and type 2.
 When size M=1, I guess the most efficient way of describing the nodes  resources is by defining 2 resource blocks: 1 block for each type of  OEO, with has many resources in the block as OEO of this tyep  available in the node. (e.g.  With 26 OEO of type 1 and 37 OEO of  type 2 - in that case only 2 Resource Block IDs needs being defined,  and their resource block info, will mention the number of resources  as being respectively 26 and 37).
 We can assume a node of size N = 5 and of size M = 3.  This means  there are 5 neighbouring nodes and the OEO resources are organized  around 3 different physical pools.  This node may be composed of a  number of devices for each of the 3 pools to be the following:

               Pool ID # of OEO type 1 # of OEO type 2
                  1          25              30
                  2          30              24
                  3          15              36
                      Composition of ressource pools

In that case, I hesitate between 3 different design solutions:
  * S1: Define 1 Resource Block Info per OEO type per Pool, each with its
      own resource Block ID.  In details that gives:
        - RBInfo1: Describes 25 OEO of type 1 - 1 RB ID associated
        - RBInfo2: Describes 30 OEO of type 2 - 1 RB ID associated
        - RBInfo3: Describes 30 OEO of type 1 - 1 RB ID associated
        - RBInfo4: Describes 24 OEO of type 2 - 1 RB ID associated
        - RBInfo5: Describes 15 OEO of type 1 - 1 RB ID associated
        - RBInfo6: Describes 36 OEO of type 2 - 1 RB ID associated
      Regarding the usage of Resource Block IDs, this solution is
      pretty efficient, especially in order to describe the
      accessibility of ressources (SharedAccessWavelengths TLVs,
      ResourceAccessibility TLVs, ResourceWaveConstraints TLVs).  But
      it is far less efficient, regarding the repetition of Resource
      Info TLVs.

  * S2: Define 1 Resource Block Info per OEO type, refering as many
      Resource Block ID as available in the node.  In details that
      gives:
        - RBInfo1: Describes 1 OEO of type 1 - (25+30+15=70) RB IDs
                associated
        - RBInfo2: Describes 1 OEO of type 2 - (30+24+36=90) RB IDs
                associated
      Regarding the usage of Resource Block IDs, this solution is far
      less efficient, but far more efficient regarding the repetition
      of Resource Info TLVs.

  * S3: Define 1 Resource Block Info per OEO type, refering the smallest
      comon divisor among each resource blocks.  In details that gives:
        - RBInfo1: Describes 5 OEO of type 1 - (5+6+3=14) RB IDs associated
        - RBInfo2: Describes 6 OEO of type 2 - (5+4+6=15) RB IDs associated
      This solution is efficient regarding both the usage of Resource
      Block IDs and the repetition of Resource Info TLVs, but this is
      possible due to "lucky" figures of OEO resources in each pool.

   Q4: Is there any of the above solution that is not respecting
       current drafts?
   Q5: Which is the solution that you consider as the most
       likely to be commonly used? 

For obvious interoperability reasons, we expect from a Standard Track document to define a single way of encoding a given node structure into the protocols. In order to achieve this, the I-D must be more specific, directive.

Pierre

-----Message d'origine-----
De : Leeyoung [mailto:[e-mail]] 
Envoyé : lundi 19 mars 2012 22:50
À : PELOSO, PIERRE (PIERRE)
Cc : [e-mail]; Greg Bernstein
Objet : RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-14.txt

Hi Pierre,

Here's our response. Please see in-line. Thanks.

Greg and Young

-----Original Message-----
From: PELOSO, PIERRE (PIERRE) [mailto:[e-mail]]
Sent: Monday, March 19, 2012 10:40 AM
To: Leeyoung
Cc: [e-mail]
Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-14.txt

 
Hi Young,

I would appreciate your answers.

Regards,

- pierre

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de PELOSO, PIERRE (PIERRE) Envoyé : jeudi 8 mars 2012 16:32 À : Leeyoung Cc : [e-mail] Objet : Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-14.txt

Hi Young and Authors,

Reading this information model draft, we were having some questions:
Quoting section 5:
Since resources tend to be packaged together in blocks of similar devices, e.g., on line cards or other types of modules, the fundamental unit of identifiable resource in this document is the "resource block".  A resource block may contain one or more resources.  As resources are the smallest identifiable unit of processing resource, one can group together resources into blocks if they have similar characteristics relevant to the optical system being modeled, e.g., processing properties, accessibility, etc.

--> This text was not changed in the v14 draft. This was slightly changed in the v13 from the v12 based on discussions in Montreal and the list. These items have been extensively discussed on the list and in person. It is time to move forward.

   Q1: It is assumable that each resource has its own ID in the machine
       system, is this understanding correct?

-->  This is a modeling decision. You could give every regenerator in your system an ID. You may only want to model the ones whose use has some flexible connectivity. We've discussed this many times.


   Q2: Does the above text means there is a normative rule enforcing that a Resource Block ID MUST be allocated to each line-card or
       other type of module?  If yes, where is this rule phrased?


--> This is an informational draft there are no normative rules in it. What a vendor or a network owner chooses to model within their system is up to them. This has always been the case in GMPLS.  Many layers of the optical network may not be modeled in a current implementation or GMPLS deployment.


   Q3: Where to find a definition of a line-card or other type of
       module?

--> The terms "line-card" and "modules" are only used as examples (the phrase "e.g., on line cards or other types of modules"), and hence do not require formal definition in this informational document. "Line card" is a common term used by almost all vendors of large switching gear such as SDH switches, OTN switch, WDM ROADS/Switches, IP routers, Carrier grade Ethernet switches, Optical access products and such. It generally denotes a pluggable (usually hot-swappable) card that contains interfaces, however, it may only perform management or other support functions.  ITU-T M.3100 section 6.3 "Physical Equipment Fragment" gives the well known management system modeling of such specific entities as line cards and modules in terms of the managed object classes "equipmentHolder" and "circuitPack".
 

Please could you clarify,

Thanks in advance,

Giovanni, Julien and Pierre

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de Leeyoung Envoyé : mercredi 7 mars 2012 19:17 À : [e-mail] Objet : [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-14.txt

Hi,

This update added a short paragraph in section 7.1 to explain that this document does not dictate encoding or placement of available labels in the relation to ISCD.

We will resolve the encoding issue of available labels either to be placed in ISCD or else in the generic encoding/ospf drafts, but not in this info draft. This info draft stays neutral with this issue so that it can close all the pending issues after this version. 

Regards,
Young

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Wednesday, March 07, 2012 12:08 PM
To: [e-mail]
Cc: [e-mail]
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-info-14.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks
	Author(s)       : Young Lee
                          Greg M. Bernstein
                          Dan Li
                          Wataru Imajuku
	Filename        : draft-ietf-ccamp-rwa-info-14.txt
	Pages           : 27
	Date            : 2012-03-07

   This document provides a model of information needed by the routing
   and wavelength assignment (RWA) process in wavelength switched
   optical networks (WSONs).  The purpose of the information described
   in this model is to facilitate constrained lightpath computation in
   WSONs. This model takes into account compatibility constraints
   between WSON signal attributes and network elements but does not
   include constraints due to optical impairments. Aspects of this
   information that may be of use to other technologies utilizing a
   GMPLS control plane are discussed.




A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-14.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-14.txt

_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp