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

From: Leeyoung <[email-masked]>
Date: Wed, 7 Mar 2012 18:16:54 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 07, 2012 12:08 PM
To: [email-masked]
Cc: [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Thu, 8 Mar 2012 16:31:40 +0100

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.

   Q1: It is assumable that each resource has its own ID in the machine
       system, is this understanding correct?
   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?
   Q3: Where to find a definition of a line-card or other type of
       module?

Please could you clarify,

Thanks in advance,

Giovanni, Julien and Pierre

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

Hi,

Regards,
Young

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Mon, 19 Mar 2012 16:39:31 +0100

Hi Young,

I would appreciate your answers.

Regards,

- pierre

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

Hi Young and Authors,

Thanks in advance,

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

Hi,

Regards,
Young

---

From: Leeyoung <[email-masked]>
Date: Mon, 19 Mar 2012 21:49:45 +0000

Hi Pierre,

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

Greg and Young

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

Hi Young,

Regards,

- pierre

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

Hi Young and Authors,

--> 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.

-->  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.

--> 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".

Thanks in advance,

-----Message d'origine-----

Hi,

Regards,
Young

---

From: Greg Bernstein <[email-masked]>
Date: Mon, 19 Mar 2012 14:56:45 -0700

Response below.
Greg B.
> 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 "reso…
--> 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.
>         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.

>         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

The terms "line-card" and "modules" are commonly used in the 
telecom/datacom industry, so this may just be a "translation issue". 
However these terms are only used as examples (in the phrase "e.g., on 
line cards or other types of modules"), and hence probably does not 
require formal definition in this informational document. "Line card" is 
a generic 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".

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Tue, 20 Mar 2012 12:54:48 +0100

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:[email-masked]] 
Envoyé : lundi 19 mars 2012 22:50
À : PELOSO, PIERRE (PIERRE)
Cc : [email-masked]; Greg Bernstein
Objet : RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-14.txt

Hi Pierre,

Greg and Young

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

Hi Young,

Regards,

- pierre

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

Hi Young and Authors,

Thanks in advance,

-----Message d'origine-----

Hi,

Regards,
Young

---

From: Greg Bernstein <[email-masked]>
Date: Wed, 21 Mar 2012 10:10:31 -0700

Hi Pierre, are these comments addressed at the 
draft-ietf-ccamp-rwa-info-14 document?  The efficient encoding that we 
worked out and discussed in Quebec City is in the 
draft-ietf-ccamp-rwa-wson-*encode*-14 draft.  See comments below.
>   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 th…
--> Sounds good to me.
>                        Composition of ressource pools
--> Okay...
>        it is far less efficient, regarding the repetition of Resource
---> Why?  In the draft-ietf-ccamp-rwa-wson-*encode*-14 draft section 
5.1 the "Resource Block Information Sub-TLV" starts with the "RB Set 
Field" that we discussed in Quebec City for meeting your efficiency 
requirements.  Please use the encoding draft. It is the normative 
document. The WSON Info draft introduces the concepts but does not 
represent efficient encoding details.
>     Q4: Is there any of the above solution that is not respecting
---> See previous comment on using encoding draft, with your starting 
solution.
>         likely to be commonly used?
---> The simplest and most straight forward...
> 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 b…
---> We've been over this many times. Current GMPLS documents of which 
we base ours on frequently give multiple encoding options, e.g., label 
set encoding in RFC3471. It is not within our scope to come up with a 
single encoding.

---

From: Leeyoung <[email-masked]>
Date: Thu, 22 Mar 2012 16:52:37 +0000

Hi Pierre,

Just to clarify one thing on S2 design solution. You wrote:

We have a notion of specifying RB ID's into a nice set of range so that you don't have to specify one by one to save lots of space.
Please see section 3.1 in which you will find the following:

The information carried in a RB set field is defined by:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Action     |C|   Reserved  |        Length                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        RB Identifier 1                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        RB Identifier n                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

When you uses Action == 2 (which corresponds to inclusive range), the inclusive range "Action" can result in very compact
encoding of resource Identifier specification. 

Thanks. 

Young

-----Original Message-----
From: PELOSO, PIERRE (PIERRE) [mailto:[email-masked]] 
Sent: Tuesday, March 20, 2012 6:55 AM
To: Leeyoung
Cc: [email-masked]; Greg Bernstein
Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-14.txt

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:

Pierre

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

Hi Pierre,

Greg and Young

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

Hi Young,

Regards,

- pierre

-----Message d'origine-----

Hi Young and Authors,

Thanks in advance,

-----Message d'origine-----

Hi,

Regards,
Young

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 22 Mar 2012 10:26:35 -0700

Hi Pierre, Young convinced me that you are really addressing the 
draft-ietf-ccamp-rwa-wson-*encode*-14 draft and not the info draft.
In that light I've got a few more comments below.
> [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 th…
-->From your diagram I'm assuming that you are putting things into M 
pools since these have pools each have a shared wavelength constraint 
from the WSS. Otherwise you could have fewer pools.
>        it is far less efficient, regarding the repetition of Resource
--> You can do this, but you are right it is slightly less efficient. We 
put more flexibility into the resource accessibility structure which you 
take advantage of in S2.
>        less efficient, but far more efficient regarding the repetition
---> This is the preferred approach with the current encoding draft. 
Resource block IDs are just numbers for you to choose from (0-65535), 
like labels.
You can also leave space in the ranges for additional OEOs that could be 
added to the node. By assigning the block IDs in a reasonable manner you 
can take advantage of the range encoding option and very efficiently 
encode the structure of your system.
>        possible due to "lucky" figures of OEO resources in each pool.
--> Seems unnecessarily complicated. Resource IDs are plentiful. I 
wouldn't worry about trying to save a few of them. Remember most 
sub-TLVs dealing with resources use an RB set field, and this supports a 
range encoding which is very efficient.
>     Q4: Is there any of the above solution that is not respecting
--> No.
>         likely to be commonly used?
--> S2. Is the most straight forward and efficient.

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Fri, 23 Mar 2012 18:08:19 +0100

Hi Greg,

Let us not play too much on words/drafts. We all know that the encoding drafts depend on the info one. And to address technical points it is not possible targetting a single draft, though my initial email answered Young's forward of the above draft. I'm sad you got confused by that.... But in case you have any doubts, yes, I'm aware the solution is described over a bunch of drafts.

See my comments in-line.

I wish you (and every other ccampers) a safe trip to Paris, where we'll have plenty of time to further address the point.

Regards,

Pierre

________________________________
De : Greg Bernstein [mailto:[email-masked]]
Envoyé : jeudi 22 mars 2012 18:27
À : PELOSO, PIERRE (PIERRE)
Cc : Leeyoung; [email-masked]
Objet : Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-14.txt

Hi Pierre, Young convinced me that you are really addressing the draft-ietf-ccamp-rwa-wson-encode-14 draft and not the info draft.
In that light I've got a few more comments below.
On 3/20/2012 4:54 AM, PELOSO, PIERRE (PIERRE) wrote:

Hi Greg and Young,

Thanks for your answers.

-->From your diagram I'm assuming that you are putting things into M pools since these have pools each have a shared wavelength constraint from the WSS. Otherwise you could have fewer pools.
Exactly, the OEO in a same pool are sharing some spatial connectivity constraints.

--> You can do this, but you are right it is slightly less efficient. We put more flexibility into the resource accessibility structure which you take advantage of in S2.
Ok,

  * 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.
---> This is the preferred approach with the current encoding draft. Resource block IDs are just numbers for you to choose from (0-65535), like labels.
You can also leave space in the ranges for additional OEOs that could be added to the node. By assigning the block IDs in a reasonable manner you can take advantage of the range encoding option and very efficiently encode the structure of your system.
 The constraint then is that I would need to refer these (70+90)=160 RB IDs in the shared_access_block TLVs, in the resource_pool_accessibility TLVs.
Whether I'm using a reasonnable manner to assign the IDs to refer in the RB infos, this would not be efficient for the other TLVs, where I could not use range.

--> Seems unnecessarily complicated. Resource IDs are plentiful. I wouldn't worry about trying to save a few of them. Remember most sub-TLVs dealing with resources use an RB set field, and this supports a range encoding which is very efficient.
As told in my previous point, the issue does not merely come from the gains or not in bytes, but from the co-existence of different solutions. And from the fact that what you state as appealingly efficient as far as the RBInfo sub-TLV are concerned, just cannot work for the other sub-TLvs. But this is a mere detail.

--> S2. Is the most straight forward and efficient.
Apart from the unnecessary difficulty of bearing 160 different resource block IDs assigned in a reasonnable manner across CP restarts etc...
And once again, I have no issues with having leafs TLVs bearing multiple encodings, which basically enable efficiency (regarding size) at little costs from the point of view of implementation of a stack.
I'm less confident in having the structure of the top-level TLV to vary from one implementation to the other. Each of the 3 solutions proposed above imposes different rules in re-constructing node internal structure from LSAs (to compute the route). This is stressing much more the implementation of the stack. I wish the CP implementation to know which mechanic use to turn a node architecture into LSAs and vice-versa. And not to choose between 3 different, ways otherwise for sure two different implementers will choose two different ones, without bothering with being compliant with the other implementer. That does not sound as safe standardisation to my hear.

Pierre

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

Hi Pierre,

Greg and Young

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

Hi Young,

Regards,

- pierre

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

Hi Young and Authors,

Thanks in advance,

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

Hi,

Regards,
Young

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

_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Greg Bernstein <[email-masked]>
Date: Fri, 23 Mar 2012 11:14:17 -0700

Hi Pierre, see below. I'm snipping non-essential stuff to reduce the 
length of the e-mail. I'm still having trouble getting your point over 
all these years, hence the need to be precise about which drafts you are 
talking about.
Greg
On 3/23/2012 10:08 AM, PELOSO, PIERRE (PIERRE) wrote:
> -- Snip --
>
>     -->From your diagram I'm assuming that you are putting things into
>     M pools since these have pools each have a shared wavelength
>     constraint from the WSS. Otherwise you could have fewer pools.
>     --> You can do this, but you are right it is slightly less
>     efficient. We put more flexibility into the resource accessibility
>     structure which you take advantage of in S2.
>     Ok,
>
>     ---> This is the preferred approach with the current encoding
>     draft. Resource block IDs are just numbers for you to choose from
>     (0-65535), like labels.
>     You can also leave space in the ranges for additional OEOs that
>     could be added to the node. By assigning the block IDs in a
>     reasonable manner you can take advantage of the range encoding
>     option and very efficiently encode the structure of your system.
>      The constraint then is that I would need to refer these
>     (70+90)=160 RB IDs in the shared_access_block TLVs, in the
>     resource_pool_accessibility TLVs.
>     Whether I'm using a reasonnable manner to assign the IDs to refer
>     in the RB infos, this would not be efficient for the other TLVs,
>     where I could not use range.
>
-->  I see Resource Pool Accessibility, Resource Block Wavelength 
Constraint, Resource Pool State, Block Shared Access Wavelength 
Availability, Resource Block Information.  The RB IDs could be allocated 
in general ranges. For your example I would do the following:
Resource type-1 assigned RB IDs 0-1000
Resource type-2 assigned RB IDs 1000-1999
Then to specific resources I would give out numbers
Pool 1 type-1 100-199
Pool 1 type-2 1000-1099
Pool 2 type-1 200-299
Pool 2 type-2 1200-1299
Pool 3 type-1 300-399
Pool 3 type-2 1300-1399
With such an assignment you've only allocated 2000 RB IDs and you have 
plenty in within that for additional pools. This also gives flexibility 
if you add more of a particular type to your pool.

Now lets look at the individual SubTLVs:
(a) Resource Block information -- two sub-TLVs with a single range RB 
set each.
(b) Resource Pool Accessibility -- Each pool is split in two ranges, so 
needs to RB sets to describe. This is not explicitly mentioned in the 
draft so we can update the description, i.e., any place on RB set can 
appear we could put in multiple.
(c) Resource Pool State -- this is specific to the type of resource so 
would just use a range per type in each pool.
  etc...

>     sub-TLVs dealing with resources use an RB set field, and this
>     supports a range encoding which is very efficient.
>     As told in my previous point, the issue does not merely come from
>     the gains or not in bytes, but from the co-existence of different
>     solutions. And from the fact that what you state as appealingly
>     efficient as far as the RBInfo sub-TLV are concerned, just cannot
>     work for the other sub-TLvs. But this is a mere detail.
>
--> Unfortunately, this is true for other aspects of GMPLS, and is in 
addition true for the connectivity matrix.
>     Apart from the unnecessary difficulty of bearing 160 different
>     resource block IDs assigned in a reasonnable manner across CP
>     restarts etc...
>
>     And once again, I have no issues with having leafs TLVs bearing
>     multiple encodings, which basically enable efficiency (regarding
>     size) at little costs from the point of view of implementation of
>     a stack.
>     I'm less confident in having the structure of the top-level TLV to
>     vary from one implementation to the other. Each of the 3 solutions
>     proposed above imposes different rules in re-constructing node
>     internal structure from LSAs (to compute the route). This is
>     stressing much more the implementation of the stack. I wish the CP
>     implementation to know which mechanic use to turn a node
>     architecture into LSAs and vice-versa. And not to choose between 3
>     different, ways otherwise for sure two different implementers will
>     choose two different ones, without bothering with being compliant
>     with the other implementer. That does not sound as safe
>     standardisation to my hear.
>
--> You are free to propose an alternative solution compatible with 
existing drafts, terminology, and GMPLS principles. I recall offering 
you a number of alternatives, prior to you starting a whole separate 
draft and delaying this project for over two years.