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

From: Leeyoung <[email-masked]>
Date: Fri, 09 Sep 2011 21:29:48 +0000

Hi,

This update (version 12) includes the following:

(i) Replaced all instances of "ingress" with "input" and all instances of "egress" with "output". 
(ii) Added clarifying text on relationship between resource block model and physical entities such as line cards.

This draft is now very mature and incorporated all the comments raised in the mailing list and the last meetings. 

Thanks,
Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, September 09, 2011 4:20 PM
To: [email-masked]
Cc: [email-masked]
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-info-12.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-12.txt
	Pages           : 27
	Date            : 2011-09-09

   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-12.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-12.txt
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 26 Sep 2011 17:58:54 +0200

Hi, 
I have the following comments on  draft-ietf-ccamp-rwa-wson-encode-12
after it being updated and in light of the WG discussions:

1) section 3.1. Resource Block Set Field:
   The information model indicates that the resource block set is
optional for the  "Resource Block Information", hence the text should be
modified as follow:
"0 - Inclusive List

     Indicates that the TLV contains zero or more RB elements that are
     included in the list."

2) section 3.1. Resource Block Set Field:
RB Identifier: as stated in section "3. Resources, Blocks, Sets, and the
Resource Pool", Resources and Resource Blocks are related to interface
cards.

GMPLS implementations are using 32-bit unnumbered interface IDs to
identify GMPLS links and also the corresponding physical resources.
OEO devices and, in the context of this document, resource or resource
group can also be identified by 32-bit unnumbered interface IDs.

 From an implementation point of view, having 16-bit resource block IDs
have several drawbacks because of the following points:
  a) Mapping exists between physical resource and unnumbered interface
IDs, this mapping is generally known by management system,
      introducing a different ID space is not optimal (new mapping
needed);
  b) Those OEOs might be used as links in a multi-node model, thus being
identified by a 32-bit unnumbered interface IDs, introducing another
space is also not optimal.

Therefore, it would be better if the resource block IDs were 32-bit
interface IDs (to be unique within the node, not because they are
representing links in this document).

3) section 3.1. Resource Block Set Field Why not define a bit set 
action, similar to the label set?

4) section 4.3. Resource Pool State Sub-TLV

The RB state refers to the number of available resources within the 
resource block, the first sentence mentions the resource pool only.
In addition, a bit map can be used even in case the resource block
contains several resources.
The following text tries to reflect this, please consider it.

    "The state of the pool is given by the number of resources available
    with particular characteristics. A resource block set is used to
    encode all or a subset of the resources of interest. The usage state
    of resources within a resource block set is encoded as either a list
    of 16-bit integer values, indicating the number of available
resources
    in the resource block, or a map of bits, indicating whether a
particular
    resource is available or not."

5) section 4.3. Resource Pool State Sub-TLV
   Typo: "RB Usage state:  Variable Length but must be a multiple of 4 
bytes." (byes->bytes)

6) section 5.1. Resource Block Information Sub-TLV

Having an Input Modulation Type List sub-sub-TLV containing a list of 
modulation formats (with an input-output bit) and an Output Modulation 
Type List sub-sub-TLV containing a list of modulation formats (with an
input-output bit) seems redundant because the bit I already indicates if
it is an output or input modulation format.

Having a single Modulation Type List sub-sub-TLV is providing the same
information with an efficient encoding, a single sub-sub-TLV type should
be used.

Same reasoning apply to the FEC Type List Sub-Sub-TLV.

7) section 5.1. Resource Block Information Sub-TLV
  Add the following text: "The order of sub-sub-TLVs does not matter,
the sub-sub-TLVs MAY be in any order."

Best Regards, 
Cyril Margaria

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Leeyoung
> Sent: Friday, September 09, 2011 11:30 PM
> To: [email-masked]
> Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-12.txt
> 
> Hi,
> 
> (ii) Added clarifying text on relationship between resource block
model
> and physical entities such as line cards.
> 
> This draft is now very mature and incorporated all the comments raised
> in the mailing list and the last meetings.
> 
> Thanks,
> Young
> 
> 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

---

From: Leeyoung <[email-masked]>
Date: Wed, 28 Sep 2011 21:47:02 +0000

Hi Cyril,

Thanks for your review and suggestions. It looks like there are two issues pending: Point #2 and #3. 
We can close the rest of the points you raised with the action specified in-line. Please let me know otherwise. 

Thanks.

Young

-----Original Message-----
From: Margaria, Cyril (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Monday, September 26, 2011 10:59 AM
To: Leeyoung; [email-masked]
Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-12.txt

Hi, 

YOUNG>> Will do in the next revision. (Closure) 

YOUNG>> The only motivation why we used 16 bits for RB ID is to reduce the space. And I think this is an internal link so it is not the real interface per se and thus there is no need to keep track of the state of RB ID like other legitimate interfaces. I don't think there is a substantial implementation issue here whether we use 16 bits or 32 bits, but if there is a strong support to use 32 bit ID over 16 bit ID, I am fine with this. Lou and Deborah, do you have any suggestion on this issue? Or other implementers? 

YOUNG>> Are you referring the Label Set encoding as follows from draft-ietf-ccamp-general-constraint-encode-05.txt

  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|    Num Labels         |          Length               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                          Base Label                           | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |     Additional fields as necessary per action                 |

The current Resource Block Set Field is encoded as follows:

  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     |E|C| Reserved  |        Length                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     RB Identifier 1           |        RB Identifier 2        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      :                               :                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     RB Identifier n-1         |        RB Identifier n        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

YOUNG>> Can you be specific about your suggestion? Are you concerned about label being 32 bit vs RB identifier being 16 bits? --- then this is basically related to your point #2. If you have other concerns, please spell them out (e.g., action field (4 bits vs 8 bits), etc..) The Num Labels field is necessary when we are indicating bit maps (Action = 4), which Is not needed for Resource Block Set; E bit is not necessary when we adopt 32 bit RB ID, but C bit is needed to indicate the connectivity nature of Resource Pool Accessibility. 

YOUNG>> Would the following encoding is what you are envisioning? If not, please suggest in detail. 

  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|                     |        Length                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                         RB Identifier 1                       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      :                               :                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                         RB Identifier n                       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

YOUNG>> Thanks. This is fine. Will add as you suggested in the revision (Closure)

YOUNG>>  Thanks. Will do s/byes/bytes in Section 4.3 (Closure)

YOUNG>> I guess what you are suggesting is as follows: 

    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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                     RB Set Field                              | 
      :                                                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |I|E|                      Reserved                             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |           Modulation Type List Sub-Sub-TLV  (opt)             | 
      :                                                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |           FEC Type List Sub-Sub-TLV    (opt)                  | 
      :                                                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Input Client Signal Type Sub-Sub-TLV      (opt)       | 
      :                                                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Input Bit Rate Range List  Sub-Sub-TLV (opt)          | 
      :                                                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Processing Capabilities List Sub-Sub-TLV (opt)        | 
      :                                                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

YOUNG>> If that's what you suggested, that is fine with me. If that is that case, I will revise with this figure in the revision. (Closure) 

YOUNG>> Thanks. This will be added in the revision (Closure)

Best Regards, 
Cyril Margaria

model
> Of [email-masked]

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Thu, 29 Sep 2011 09:28:38 +0200

Hi Young,

See in line.
 
Best regards,

- pierre

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Leeyoung
Envoyé : mercredi 28 septembre 2011 23:47
À : Margaria, Cyril (NSN - DE/Munich); [email-masked]
Objet : Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-12.txt

Hi Cyril,

Thanks.

Young

-----Original Message-----
From: Margaria, Cyril (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Monday, September 26, 2011 10:59 AM
To: Leeyoung; [email-masked]
Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-12.txt

Hi, 

PIERRE>> As an implementer I am in favor of 32 bits, which I find more convenient for the same reasons as the one exposed by Cyril.

  0                   1                   2                   3 

  0                   1                   2                   3 

  0                   1                   2                   3 

    0                   1                   2                   3 

PIERRE>> Actually Young, I take the modification proposed is slightly diffrent it is more to have an I and E bits directly inside each of the Modulation Type and each of the FEC type field.
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S|I|E|    Modulation ID        |          Length               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I bit set to 1 states that the modulation is valid as ingress
E bit set to 1 states that the modulation is valid as egress

The same for the FEC type list.
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S|I|E|       FEC ID            |          Length               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Best Regards, 
Cyril Margaria

model

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 29 Sep 2011 11:07:40 +0200

Hi Young, 

For point 1,4,5,7 its ok.
I updated the title BTW 

I clarified some points inline. 

Best Regards
Cyril

> From: ext Leeyoung [mailto:[email-masked]]
> Sent: Wednesday, September 28, 2011 11:47 PM
> To: Margaria, Cyril (NSN - DE/Munich); [email-masked]
> We can close the rest of the points you raised with the action
> specified in-line. Please let me know otherwise.
> 
> Thanks.
> 
> Young
> 
> 

<snip>

> YOUNG>> The only motivation why we used 16 bits for RB ID is to reduce
> the space. And I think this is an internal link so it is not the real
> interface per se and thus there is no need to keep track of the state
> of RB ID like other legitimate interfaces. I don't think there is a
> substantial implementation issue here whether we use 16 bits or 32
> bits, but if there is a strong support to use 32 bit ID over 16 bit
ID,
> I am fine with this. Lou and Deborah, do you have any suggestion on
> this issue? Or other implementers?

CYRIL>> The most bothering point of having 16 bit is for management
system
 that needs to learn a new mapping between control plane resources and 
 management plane resource. Having 32 bit ids make this more transparent
to 
 management applications. 

> YOUNG>> Are you referring the Label Set encoding as follows from
draft-
> ietf-ccamp-general-constraint-encode-05.txt
> 
>   0                   1                   2                   3
:
> 
> YOUNG>> Can you be specific about your suggestion? Are you concerned
> about label being 32 bit vs RB identifier being 16 bits? --- then this
> is basically related to your point #2.

CYRIL>> No, this is independent to the length of the RB identifier

> If you have other concerns,
> please spell them out (e.g., action field (4 bits vs 8 bits), etc..)
> The Num Labels field is necessary when we are indicating bit maps
> (Action = 4), which Is not needed for Resource Block Set; E bit is not
> necessary when we adopt 32 bit RB ID, but C bit is needed to indicate
> the connectivity nature of Resource Pool Accessibility.
> 
>       | Action|C|                     |        Length
|
>       |                         RB Identifier 1
|
:
>       |                         RB Identifier n
|

My suggestion is to add the following text and format : 
Action : 
  1 - Reserved
  3 - Reserved	
  4 - Bitmap Set

When Action is 4 (bitmap set) the format of the Resource block set is
the following (with 16 bit ids):
       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 = 4 |E|C| Reserved  |        Length                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     base RB Identifier        |Bit Map(Lowest numerical RB Id)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Bit Map(Highest numerical RB Id)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Each bit in the bit map represents a
   particular RB Id with a value of 1/0 indicating whether the RB id is
   in the set or not. Bit position zero represents the lowest RB Id and
   corresponds to the base RB identifier, while each succeeding bit
position
   represents the next RB identifier in numerical order. 

For example 

       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 = 4 |E|C| Reserved  |        Length                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     base RB Identifier =10    |1|0|1|1|0|0|0|0|1|0|1|1|0|1|0|1|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0|0|0|1|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Correspond to the following set of RB ids:
10,12,13,18,20,21,23,25,30

With 32 bits ids : 
       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 = 4 |E|C| Reserved  |        Length                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     base RB Identifier                                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Bit Map Word #1 (Lowest numerical RB Id)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Bit Map Word #N(Highest numerical RB Id)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The previous example will be : 
       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 = 4 |E|C| Reserved  |        Length                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     base RB Identifier =10                                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|1|1|0|0|0|0|1|0|1|1|0|1|0|1|0|0|0|0|1|0|0|0|0|0|0|0|0|0|0|0|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

General constraints encoding introduce a bitmap set for a set of IDs 
for efficiency, this can apply to each encoding representing a set of
ids where you
can define a group/calculate ID = baseID + n.
 
>       |                     RB Set Field
|
>       :
:
>       |I|E|                      Reserved
|
>       :
:
>       :
:
>       :
:
>       :
:
>       :
:
> 
> 
> YOUNG>> If that's what you suggested, that is fine with me. If that is
> that case, I will revise with this figure in the revision. (Closure)

This is what I mean, the logic of "if no egress FEC/Modulation is
present, 
this is implicitly the same as the ingress FEC/Modulation".  

This proposal do not change the format of the FEC and Modulation.

 <snip>

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 29 Sep 2011 11:49:26 +0200

Hi, 

I have the following comments/question regarding the document
draft-ietf-ccamp-rwa-info-12:

1) Section 5:
The paragraph
"A resource block may contain one or more resources.
   As resource blocks 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."

It's a bit confusing to me, from the previous paragraph I understand
that a resource can be : 
- One regenerator
- One wavelength converter
- One OEO
In summary one resource can process one signal/Label.

>From this I would understand that the resource (not the resource group)
is 
the smallest identifiable unit of signal processing and in the
information model 
we do only need to address the resource block because all resources
within that group 
are equivalent.

In that case the following change would be maybe more understandable

"A resource block may contain one or more resources.
 As resources are the smallest identifiable unit of signal processing,
 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.

For routing the information model identifies the resource block because
all resources in the resource block  are equivalent.
"

2) Section 5.2.
  Change the definitions as  follow (according to the encoding):
<ResourceBlockInfo> ::= ([<ResourceSet>] <InputConstraints>
   [<ProcessingCapabilities>] <OutputConstraints>)*

<InputConstraints> ::= <SharedInput> [<ModulationTypeList>]
   [<FECTypeList>] [<BitRateRange>] [<ClientSignalList>]

<OutputConstraints> := <SharedOutput> [<ModulationTypeList>]
   [<FECTypeList>]

<ProcessingCapabilities> ::= [<NumResources>]
   [<RegenerationCapabilities>][<FaultPerfMon>][<VendorSpecific>]

3) 5.3.6. Processing Capability List
  As previous comment : 
<ProcessingCapabilities> ::= [<NumResources>]
   [<RegenerationCapabilities>][<FaultPerfMon>][<VendorSpecific>]

4) 5.3.6. Processing Capability List	
  The document state : 
"The processing capability list sub-TLV is a list of processing
  functions that the WSON network element (NE) can perform on the
signal including:"

I think this is mixing signal processing capabilities and resource block
configuration,
The following text would be more accurate:
"The processing capability list contain the list of processing
   capabilities that the identified resources can perform on the  signal
and the number of those resources"

As the list contains the capabilities of the resources and their maximum
number. Maybe a statement why the maximum number of resource is
considered in the capabilities rather than the state would help clarify.

5) Section 5.3.1. Shared Input or Output Indication:
  Indentation is not correct

6) Section 5.3.1. Shared Input or Output Indication:
  The following text could be added : "This is similar to the Link Label
Exclusivity restriction"

7) Section   6.6. Port Label (Wavelength) Restrictions
   The Label are not only applicable to Wavelength label, removing  the
Wavelength from the title section would make this more clear.
The section mention only wavelengths but is generally applicable (For
instance in OTN with fixed multiplex structure), wavelength should
always be in parenthesis.

>From the information model it is implicit that label restriction coming
from the connectivity matrix are reflected on all the links connected to
this matrix. Making this explicit would help the document to be more
clear. Another possibility would be to add this information to the
connectivity matrix encoding itself, as it is static.

model

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 29 Sep 2011 11:55:42 +0200

Hi Young, Pierre 

Please see inline, 

BR,
 Cyril

<cut>

> input-output bit) seems redundant because the bit I already indicates
> if it is an output or input modulation format.
> 
> information with an efficient encoding, a single sub-sub-TLV type
> should be used.
> 
|
:
|
:
:
:
:
:
> YOUNG>> that case, I will revise with this figure in the revision.
> YOUNG>> (Closure)
> 
> PIERRE>> Actually Young, I take the modification proposed is slightly
> diffrent it is more to have an I and E bits directly inside each of
the
> Modulation Type and each of the FEC type field.
>       0                   1                   2                   3
> I bit set to 1 states that the modulation is valid as ingress E bit
set
> to 1 states that the modulation is valid as egress
> 

Cyril>> As stated in the other response, this proposal of having a bit
 for Ingress and Egress is another proposal, also interesting but it
 checked against the signaling document. 
 It possible to keep the FEC and Modulation Type as existing and use
well 
 defined processing rules 

BR

---

From: Leeyoung <[email-masked]>
Date: Fri, 30 Sep 2011 22:21:56 +0000

Hi Cyril,

Regarding your point #3, the main motivation for bitmap representation of label (wavelength) was based on standard/well-defined/global contiguous ID. That is, once you know the lowest level of wavelength grid in the label/wavelength set, you can derive the rest easily based on the "globally" identifiable wavelength grid (per RFC6205 and G.694.1/2). 

Here the RB ID is local and arbitrary and as such I have a little hesitation to expand the Action field for bit map representation. If we define RB ID ={1,2,3,..N}, then it would be able to extract, for instance, the next RB ID after 1 is obviously 2. But we don't know if such is the case always. The operator can give any scheme for RB ID and it is strictly a local matter so assuming "monotonous increase" (as the example) may not work. 

What do you think? 

We still have point #2 (32 bits vs 16 bits) open --- I haven't seen enough implementers input on this point yet. 

I concur with you on point #6 (in your response to Pierre), is there any issue left on point #6? 

Best Regards,
Young

-----Original Message-----
From: Margaria, Cyril (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Thursday, September 29, 2011 4:08 AM
To: Leeyoung; [email-masked]
Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-wson-encode-12

Hi Young, 

Best Regards
Cyril

<snip>

ID,

draft-
:

|
|
:
|

For example 

       0                   1                   2                   3

With 32 bits ids : 
       0                   1                   2                   3

 
> if
> should
|
:
|
:
:
:
:
:

 <snip>