Re: [CCAMP] I-D Action:draft-khuzema-ccamp-gmpls-signaling-g709-01.txt

Dear Rajan

I have read the draft, here are some comments, please consider:

5.1 Multi-stage Label

You defined the Multi-stage label as the following format
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Num MUX Stages|  OD(T)Uk (ST) |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Tributary Slot Info (Stage-1)                |
   |                        (Variable Length)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              . . .                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Tributary Slot Info (Stage-n)                |
   |                        (Variable Length)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Below is the Tributary Slot Info
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    ODUj (ST)  | T |  Length   |      Tributary Port Number    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Variable Length Bit Map (4-byte boundary aligned)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Comments 1：I did not see the explanation of ODUK(ST) or ODUj(ST), S 
meaning Switching capability and T means Terminating capability? 

Comments 2: I agree with you that there are some scenarios that needs 
non-FA scheme based multi-stage , citing from your documents
         ( Note: Multi-stage Label is NOT intended to facilitate the 
creation of  FA-LSP or Hierarchical LSP. It is basically used to 
           eliminate the need for FA-LSP in some obvious scenarios.)

Be glad to see that you consider the information of multi-stage labels, 
but maybe you can redefine this label format as below, 
which can improve the encoding efficiency without losing the information 
about multi-stage labels.

    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  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | GPID                          | T |         TPN               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |      Bitmap  .........                                         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   ~                                                                ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Here the GPID are following the same usage defined in section 5.5.2.1 of 
the document 
 http://tools.ietf.org/html/draft-ashok-ccamp-gmpls-ospf-g709-03 and the 
numbers of T/TPN/bitmap depends on the numbers of multi-stage.

The encoding of Generalized Label is as follows:

   Case-1: ODUk mapping into OTUk
   GPID = ODUk
   T and TPN SHOULD be set to zero; bitmap is not required.

   Case-2: ODUj mux into ODUk
   GPID=ODUk-ODUj 
   TPN = <specified as per Section 5>
   BitMap = <TSs reserved for ODUj are set to 1>

   Case-3 ODUh mux into ODUj into ODUk 
   GPID=ODUk-ODUj-ODUh. 
   The fit T/TPN/bitmap sequence indicates the usage of ODUk-ODUj; 
and the second T/TPN/bitmap sequence indicates the usage of ODUj-ODUh.

Apparently, this is the unified encoding format suitable for single-stage 
and multi-stage multiplexing. 

According to the example you provided in section 9 (ODU0-ODU2-ODU3 
multiplexing between node B and node C)

   +-----+             +-----+             +-----+             +-----+
   | OTN |             | OTN |             | OTN |             | OTN |
   | SW  |<-OTU2(1.25)>| SW  |<-OTU3(2.5)->| SW  |<-OTU2(1.25)->| SW  |
   |  A  |             |  B  |             |  C  |             |  D  |
   +-----+             +-----+             +-----+             +-----+

The label format between B and C is
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  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | GPID=ODU3-ODU2-ODU0          |T=2|         TPN=1…4            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Bitmap=ODU3-ODU2             |T=1|         TPN=1…8            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |Bitmap=ODU2-ODU0|      padding (0)                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Just my two cents, compared to the old solution, this one is more 
efficient without losing any information.

Best regards

Fei
*********************************************************************
Fei Zhang Ph.D.
Add:System Architecture Dept./ZTE Central R&D Institute/R&D/ZTE
Tel:86-025-52877612
Mobile:86-13914483568
Mail: zhang.fei3@zte.com.cn
*********************************************************************

Rajan Rao <rrao@infinera.com> 
发件人:  ccamp-bounces@ietf.org
2011-03-15 09:17

收件人
"ccamp@ietf.org" <ccamp@ietf.org>
抄送

主题
Re: [CCAMP] I-D Action:draft-khuzema-ccamp-gmpls-signaling-g709-01.txt

Hi,

We have submitted updates to the following draft. Please review & comment.

http://tools.ietf.org/html/draft-khuzema-ccamp-gmpls-signaling-g709-01

Thanks
Authors

-----Original Message-----
From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] 
On Behalf Of Internet-Drafts@ietf.org
Sent: Monday, March 14, 2011 12:45 PM
To: i-d-announce@ietf.org
Subject: I-D Action:draft-khuzema-ccamp-gmpls-signaling-g709-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

                 Title           : Signaling Extensions for Generalized 
MPLS (GMPLS) Control of G.709 Optical Transport Networks
                 Author(s)       : K. Pithewan, et al.
                 Filename        : 
draft-khuzema-ccamp-gmpls-signaling-g709-01.txt
                 Pages           : 21
                 Date            : 2011-03-14

As OTN network capabilities continue to evolve, there is an increased need 
to support GMPLS control for the same. [RFC4328] introduced GMPLS 
signaling extensions for supporting early version of G.709 [G.709-v1].The 
basic routing considerations from signaling perspective is also specified 
in [RFC4328].

The recent revision of ITU-T Recommendation G.709 [G.709-v3] and [GSUP.43] 
have introduced new ODU containers (both fixed and
flexible) and additional ODU multiplexing capabilities, enabling support 
for optimal service aggregation.

This document extends [RFC4328] to provide GMPLS signaling support for the 
new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling 
extensions described in this document caters to ODU layer switching only. 
Optical Channel Layer switching considerations in [RFC4328] are not 
modified in this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-khuzema-ccamp-gmpls-signaling-g709-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version of the 
Internet-Draft.
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp