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

From: Lou Berger <[email-masked]>
Date: Sat, 01 Oct 2011 07:54:29 -0400

> Lou and Deborah, do you have any suggestion on this issue?

Young,
	32 bit identifiers are fairly common on routers/IP-based control
systems, and lots of implementations understand how to generate such
identifiers in a dynamic and platform-relevant fashion.  My *personal*
opinion is that unless there's a good reason to not use the norm, i.e.,
32-bit identifiers, they should be used.  Keep in mind that the
identifiers in question are in the control plane (where bits are less
precious).

BTW I see this issue as much less important than ensuring that the
solution can work across graceful restarts.

Lou

On 9/28/2011 5:47 PM, Leeyoung wrote:
> 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, 
> 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."
> 
> YOUNG>> Will do in the next revision. (Closure) 
> 
> 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).
> 
> 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? 
> 
> 
> 3) section 3.1. Resource Block Set Field Why not define a bit set 
> action, similar to the label set?
> 
> 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                       | 
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> 
> 
> 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."
> 
> YOUNG>> Thanks. This is fine. Will add as you suggested in the revision (Closure)
> 
> 
> 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)
> 
> YOUNG>>  Thanks. Will do s/byes/bytes in Section 4.3 (Closure)
> 
> 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.
> 
> 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) 
> 
> 
> 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."
> 
> YOUNG>> Thanks. This will be added in the revision (Closure)
> 
> 
> Best Regards, 
> Cyril Margaria
> 
> 
>> -----Original Message-----
>> 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,
>>
>> 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
>> _______________________________________________
>> CCAMP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
>

---

From: Giovanni Martinelli <[email-masked]>
Date: Thu, 06 Oct 2011 23:04:37 +0200

> identifiers in question are in the control plane (where bits are less
+1
> solution can work across graceful restarts.
does it means that  solution on the table needs some consideration about 
restart?

Cheers
G

---

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

Hi, 

Please see inline

> From: ext Leeyoung [mailto:[email-masked]]
> Sent: Saturday, October 01, 2011 12:22 AM
> To: Margaria, Cyril (NSN - DE/Munich); [email-masked]
> Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-wson-encode-
> 12
> 
> 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?
As you stated, this may not be always the case, but it can happen,
typically
If the node chooses to bundle the resources in resource block, then its
likely
to have monotonous increase, so I think it is worth to generalize the
usage of bit set
to IDs where its possible to define ID(n) = base_ID . n = (base_ID .
(n-1)) .1 ... etc
The document need to define the "." operation for RFC6205 labels
(already done), RB Id and 
Possibly interface IDs (for general-encoding). In the context of
general-encoding, new
 label format can simply define this operation and the bitmap set id
list can be used.

> 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?
> 
>From my point of view #6 can be closed, but the point from Pierre is
different from #6 (how many sub-TLVS), 
it is more a point #7 on the content of the sub-TLV, which I support
because of the following points:
  - having 2 bit guarantees that the size is the minimum one
  - its more explicit and makes processing less complex (one less rule) 

BR
Cyril

> Sent: Thursday, September 29, 2011 4:08 AM
> Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-wson-encode-
> 12
> 
> 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>
> > RB Identifier: as stated in section "3. Resources, Blocks, Sets, and
> > the Resource Pool", Resources and Resource Blocks are related to
> > interface cards.
> >
> >   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.
> >
> > 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +
> >      |                          Base Label
> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +
> :
> > 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
>       |    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
>       |    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
>       |    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
>       |    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.
> 
> >
> >
> > 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.
> >
> >       |                     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: Leeyoung <[email-masked]>
Date: Thu, 27 Oct 2011 13:09:02 +0000

Hi Cyril,

Please see inline for my comment. Thanks.

I will update the draft shortly. It seems that I still have problem of your point #3.

The issue of 16 bits vs 32 bits, I will take 32 bit solution. Other than that, I think
We have resolved all the issues you raised in the beginning. 

Thanks,

Young

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

Hi, 

Please see inline

we
and
the

YOUNG>> This may create interoperability problem as I said before. This is an internal policy issue as to how to name the resource block ID. Different operators have their preferences and it is beyond what we should do in the standard. 

YOUNG>> I can close Point #6 you raised now. I am not sure what this point is. 

BR
Cyril

real
state
transparent
indicate
|
Id)|
:
|
is
and
|
|
|
|
:
|
|
|
indicates