Hi,

Just wanted to recap and start a discussion for

1.      WSON RWA Information draft (http://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-info/) and

2.      WSON Generic Encoding draft (http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/).

The authors of the WSON RWA information drat believe that the draft is stable and can move forward to WG LC. Please bring up any issues you are aware of this draft before we are ready to move on.

Regarding the WSON Generic Encoding draft, we have a couple of issues we need to discuss. The first one is how the current generic encoding deals with flex-grid issue. The second issue is where to put ISCD encoding.

·         Let’s discuss the first issue. As part of the WSON generalization effort the WSON Info draft and the General Constraints encoding draft represents link resources (spectrum, time slots, etc...) in a general way in the. This should is applicable to Flex Grid and other technologies.

In section 7.1 of the WSON Info Model we define two important types of link information "available labels" and "shared backup labels". These fields are used to indicate the availability of link "resources". This is similar to the notion of the use of the Label Set of RFC3471 (GMPLS signaling). Note that in MPLS RSVP signaling, RFC3209, there is also the notion of "label range" restriction (from the old ATM and Frame Relay days).  In MPLS, labels do not represent link bandwidth resources (spectrum, time slot, etc.) while in most GMPLS technologies they do. From the WSON routing and general constraint routing perspective we are concerned with the link "resources" and the "available labels" serves this purpose.

In section 2.2 of the General Constraint Encoding draft we define a Label Set field that is then used to represent available resources on a link. These resources may be time slots within a SONET/SDH or G.709 hierarchy or chunks of frequency spectrum in a WDM system. In appendix A.2 of the General Constraint Encoding draft we give examples for the WSON case based upon the label format in RFC6205. However the mechanisms of the Label Set field could be used with SONET/SDH label encoding of RFC4606.  It should be noted that many pre-standard GMPLS systems from different vendors all used bit maps to track SONET/SDH time slots.  Flex-grid systems (G.694.1 2012) work with an ITU-T grid and center frequency hence one can still use the Label Set field to represent optical frequency spectrum resources. One could use a new label type as a base or a RFC6205 label type with finer granularity.  If one wishes to restrict the choices used with a particular technology that could be handled in a technology specific OSPF extension. This implies that when flex grid work becomes a viable CCAMP work, the current generic encoding works very well with the anticipated extension to flex-grid based WSON (SSON). Any encoding changes due to flex-grid can be added into technology specific OSPF extension. The development of flex-grid would not and should not interfere with the current generic encoding draft.

·         The second issue is where to put the "available labels" and "shared backup labels" information.

As we pointed out above these fields were designed to be applicable to multiple technologies (TDM, WSON, Flex grid).  These are link specific and "dynamic" (can change with subsequent LSP addition or removal). It has been suggested that this information could be added to the ISCD of RFC4203. This is somewhat problematic, though maybe not prohibitively so. First the available place for this would be the "Switching Capability-specific information" field. Currently this field is defined for TDM and for LSC "there is no Switching Capability specific information field present."  An alternative would be to define new sub-TLVs of the TE-Link TLV.  Are there strong opinions out there? It seems that trying to use the ISCD has more impact on previous RFCs.

Regards,

Greg and Young