Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexible-grid-ospf-ext-04

[Dieter Beller <[e-mail]>]

Hi Fatai, CCAMPers,

I've reviewed this document and I have the following comment:

Section 4.1:

4.1. ISCD Extensions for Flexi-grid

         Value                       Type

         -----                       ----

      152 (TBA by IANA)           Flexi-Grid-LSC capable

   Switching Capability and Encoding values MUST be used as follows:

              Switching Capability = Flexi-Grid-LSC

              Encoding Type = lambda [as defined in https://tools.ietf.org/html/rfc3471" rel="nofollow">RFC3471]

   When Switching Capability and Encoding fields are set to values as
   stated above, the Interface Switching Capability Descriptor MUST be
   interpreted as in [https://tools.ietf.org/html/rfc4203" rel="nofollow">RFC4203] with the optional inclusion of one or
   more Switching Capability Specific Information sub-TLVs.

draft-ietf-ccamp-flexible-grid-ospf-ext-04 defines the Switching Capability Specific Information sub-TLVs, but the ISCD as defined
in RFC4203 contains "Max LSP Bandwidth at priority x" fields in the  generic ISCD part and these fields do IMHO not make
sense for flex grid (see below). The draft does not say how these fields shall be filled.


Excerpt from RFC4203:

1.4.  Interface Switching Capability Descriptor

   The Interface Switching Capability Descriptor is a sub-TLV (of type
   15) of the Link TLV.  The length is the length of value field in
   octets.  The format of the value field is as shown below:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Switching Cap |   Encoding    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 1              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 2              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 3              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 4              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 5              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 6              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 7              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Switching Capability-specific information              |
   |                  (variable)                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Switching Capability (Switching Cap) field contains one of the
   following values:

      1     Packet-Switch Capable-1 (PSC-1)
      2     Packet-Switch Capable-2 (PSC-2)
      3     Packet-Switch Capable-3 (PSC-3)
      4     Packet-Switch Capable-4 (PSC-4)
      51    Layer-2 Switch Capable  (L2SC)
      100   Time-Division-Multiplex Capable (TDM)
      150   Lambda-Switch Capable   (LSC)
      200   Fiber-Switch Capable    (FSC)

   The Encoding field contains one of the values specified in https://tools.ietf.org/html/rfc4203#section-3.1.1" rel="nofollow">Section
   https://tools.ietf.org/html/rfc4203#section-3.1.1" rel="nofollow">3.1.1 of [https://tools.ietf.org/html/rfc4203#ref-GMPLS-SIG" title='"Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"' rel="nofollow">GMPLS-SIG].

   Maximum LSP Bandwidth is encoded as a list of eight 4 octet fields in
   the IEEE floating point format [https://tools.ietf.org/html/rfc4203#ref-IEEE" title='"IEEE Standard for Binary Floating-Point Arithmetic"' rel="nofollow">IEEE], with priority 0 first and
   priority 7 last.  The units are bytes (not bits!) per second.

   The content of the Switching Capability specific information field
   depends on the value of the Switching Capability field.

Minor nits:

page 5 typo:
'Chanel Spacing' instead of 'Channel Spacing'

page 7 editorial:
'Flexi-Grid-LSC capable': capable should be removed (already included in the LSC abbreviation).


Thanks,
Dieter

On 25.06.2016 04:35, Fatai Zhang wrote:

Hi all,

 

This starts a two week working group last call on [draft-ietf-ccamp-flexible-grid-ospf-ext-04].

 

The working group last call ends on Friday, July 8th. Please send your comments to the CCAMP mailing list.

 

As is always the case, positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome. This is useful and important, even from authors.

 

Since the WG chairs and secretary are co-authors/co-contributor of this draft, if anyone is willing to be the shepherd of the document, please volunteer.

 

Note that no IPR was disclosed against this document.

 

 

 

Thanks

 

Fatai and Daniele

 

_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ccamp

--

Dieter Beller
ASON/GMPLS Project Manager
IP/Optical Networks, Optics, Nokia

t: [phone] | m : [phone] | OnNet: 259 43125
[e-mail]

Alcatel-Lucent Deutschland AG | Lorenzstr. 10 | 70435 Stuttgart

Sitz der Gesellschaft | Domicile of the Company: Stuttgart · Amtsgericht Stuttgart HRB 4026
Vorsitzender des Aufsichtsrates | Chairman of the Supervisory Board: Prof. J. Menno Harms
Vorstand | Board of Management: Wilhelm Dresselhaus (Vorsitzender | Chairman) · Hans-Jörg Daub · Ralf Niederberger

This e-mail and its attachments, if any, may contain confidential information.
If you have received this e-mail in error, please notify us and delete or destroy the e-mail and its attachments, if any, immediately.
If you have received this e-mail in error, you must not forward or make use of the e-mail and its attachments, if any.