Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

"Zhangxian (Xian)" <zhang.xian@huawei.com> Thu, 26 February 2015 01:37 UTC

Return-Path: <zhang.xian@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8597C1A92E8 for <ccamp@ietfa.amsl.com>; Wed, 25 Feb 2015 17:37:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.279
X-Spam-Level: *
X-Spam-Status: No, score=1.279 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKlCPY1O0wPq for <ccamp@ietfa.amsl.com>; Wed, 25 Feb 2015 17:37:08 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1D01A92E3 for <ccamp@ietf.org>; Wed, 25 Feb 2015 17:37:06 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPQ20938; Thu, 26 Feb 2015 01:37:05 +0000 (GMT)
Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Feb 2015 01:37:04 +0000
Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.61]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Thu, 26 Feb 2015 09:36:55 +0800
From: "Zhangxian (Xian)" <zhang.xian@huawei.com>
To: Rajan Rao <rrao@infinera.com>, "CCAMP (ccamp@ietf.org)" <ccamp@ietf.org>, "'Ramon Casellas'" <ramon.casellas@cttc.es>
Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt
Thread-Index: AQHQUWSz3C0/5iEpxEKpJ6rsUeCIXA==
Date: Thu, 26 Feb 2015 01:36:54 +0000
Message-ID: <C636AF2FA540124E9B9ACB5A6BECCE6B4717EFA0@SZXEMA512-MBS.china.huawei.com>
References: <E0C26CAA2504C84093A49B2CAC3261A438C46E2F@SZXEMA504-MBX.china.huawei.com> <23655678914b4af2b5c3b71ee31bd930@sv-ex13-prd1.infinera.com> <E0C26CAA2504C84093A49B2CAC3261A438C4713E@SZXEMA504-MBX.china.huawei.com> <e5cbf9266c534e8bbdb0f427cb4c64eb@sv-ex13-prd1.infinera.com> <E0C26CAA2504C84093A49B2CAC3261A438C5B0E1@SZXEMA504-MBX.china.huawei.com> <2f2dfa0579c44d9f878526197442ae8d@sv-ex13-prd1.infinera.com> <1b93fa3f01e54e78ac7796e70154205b@sv-ex13-prd1.infinera.com> <E0C26CAA2504C84093A49B2CAC3261A438C5FDF5@SZXEMA504-MBX.china.huawei.com> <fda31af8ac0e4bdcb5ba4305239a28aa@sv-ex13-prd1.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4812888A23@ESESSMB301.ericsson.se> <98bf7b4a8a424578bab48c9892aabba1@sv-ex13-prd1.infinera.com>
In-Reply-To: <98bf7b4a8a424578bab48c9892aabba1@sv-ex13-prd1.infinera.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.104.209]
Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B4717EFA0SZXEMA512MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/PD-mKudI4eeJ3IsC7mAdqONchuc>
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Feb 2015 01:37:13 -0000

Hi, Rajan,

    As I was not involved earlier, I find the following may be  a bit long for others in the WG to get involved.  Before I dive into the discussion and share my thoughts, am I accurate if I recap the question as:

   You think the existing text in draft-ietf-ccamp-flexible-grid-ospf-ext-01 do not support the following:

1)      Do not support priority;

2)      Do not convey the min & max LSP bandwidth information in the SCSI field;

Could you confirm my interpretation of your issue?

The following is my thoughts ( subject to change if the question I recapped above is not as exact as what you want to say):

The  current method is to reuse what has already been proposed for WSON. So it reuses the SCSI field defined in WSON-OSPF draft (https://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-15#section-3.1). So, it DOES support priority (see the details are in [GEN-ENCODE] draft-ietf-ccamp-general-constraint-encode-20). Exactly because of the same reason, the draft under discussion uses label set field to describe what frequency slots are available. So, although it allows for all different varieties supported by [GEN-ENCODE] (i.e., list, bitmap, inclusive, exclusive etc.), the method does not see the need of specify the max&min LSP bandwidth since it can be naturally deduced from the available frequency spectrum information conveyed.

The above discussion actually reminds me of a question Ramon raised up a while ago among the authors of this draft, what has been defined in WSON-OSPF is truly usable labels in signaling. But with Flexi-grid, it is not true anymore. For example, although we use Inclusive Label Range to describe available frequency range, say the example in Section 4.4 of  draft-ietf-ccamp-flexible-grid-ospf-ext-01 (assume m=1), none of these labels are directly usable if what is actually requested is a bandwidth with m=2.  I myself do not see any issue as long as we make it clear we use the format just to describe what resource available NOT usable labels. Since it is a WG draft, it is worthwhile to solicit what you think?

Cheers,
Xian

From: Rajan Rao [mailto:rrao@infinera.com]
Sent: 2015Äê2ÔÂ26ÈÕ 7:17
To: Daniele Ceccarelli; Zhenghaomian; Fatai Zhang; CCAMP (ccamp@ietf.org)
Cc: Khuzema Pithewan; Iftekhar Hussain; Zhangxian (Xian); Ramon Casellas; Oscar Gonzalez de Dios
Subject: RE: [CCAMP] ת·¢: I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Daniele,

Sure.  Added WG in the list for comments.

Thx
Rajan

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Wednesday, February 25, 2015 12:45 PM
To: Rajan Rao; Zhenghaomian; Fatai Zhang
Cc: Khuzema Pithewan; Iftekhar Hussain; Zhangxian (Xian); Ramon Casellas; Oscar Gonzalez de Dios
Subject: RE: [CCAMP] ת·¢: I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Hi all,

This is a really interesting discussion and since we¡¯re speaking about a working group draft I think we should continue con the mailing list.
Please include the WG in your reply.

BR
Daniele

From: Rajan Rao [mailto:rrao@infinera.com]
Sent: mercoled¨¬ 25 febbraio 2015 19:56
To: Zhenghaomian; Fatai Zhang
Cc: Khuzema Pithewan; Iftekhar Hussain; Zhangxian (Xian); Daniele Ceccarelli; Ramon Casellas; Oscar Gonzalez de Dios
Subject: RE: [CCAMP] ת·¢: I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Haomian,

The priority in each layer is independent.  The intent of explicitly carrying priority info in the advertisement is to allow for LSP creation at different priorities.  Note that priority defined in OTN RFC don¡¯t apply here as it is a different layer.   You can have L0-LSP setup at priority-1 but L1-Telink (OTN link) formed out of this may advertise all 8 or subset of them.  It is an implementation choice.  I don¡¯t see any conflicts here.

Once we agree on the following items we can figure out TLV encoding options.


1.      Allow for Advertisement of Min & Max slot widths at different priorities ¨C up to 8

2.      Min/Max slot width field ¨C 16 bit instead of 8  (I see you are agreeing to this change below)

3.      Max LSP Bandwidth ¨C this was debated in previous meetings but no firm conclusion.

Thx
Rajan

From: Zhenghaomian [mailto:zhenghaomian@huawei.com]
Sent: Tuesday, February 24, 2015 11:35 PM
To: Rajan Rao; Fatai Zhang
Cc: Khuzema Pithewan; Iftekhar Hussain; Zhangxian (Xian); Daniele Ceccarelli; Ramon Casellas; Oscar Gonzalez de Dios
Subject: ´ð¸´: [CCAMP] ת·¢: I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Hi, Rajan,

Thanks for the information, I noticed there is a change talking about extending Flexi-grid data plan to satisfy requirements in RFC4202. I forward this email to all the authors of OSPF draft to advertise your comments:)

Firstly let¡¯s recall the sub-TLV format in draft-dhillon-ccamp-flexgrid-ospfte-ext as follow:

  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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type=1            |              Length           |
   +---------------------------------------------------------------+
   |Slice Spacing | Pri |                    Reserved              |
   +---------------------------------------------------------------+
   |               N-Start         |          Num of Slices        |
   +---------------------------------------------------------------+
   |         Min Slot Width        |       Max Slot Width          |
   +---------------------------------------------------------------+
   |                                                               |
   |                   Bit-Map showing Available Slices           |
   |                     (up to 48 bytes)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Then I share my understanding on your concern. Compared with sub-TLV in section 4.3 of draft-ietf-ccamp-flexible-grid-ospf-ext-01, I highlight the difference as follow:

In your proposal,

1)      Slice Spacing is preferred to be carried in the  sub-TLV;

2)      Priority bits are preferred to be included in sub-TLV;

3)      Min/Max Widths should both be 16-bit;

4)      N-start and Num of Slices to represent the spectrum rather than C.F.G and S.W.G;

Below please find my comments:
Firstly I believe both of your structure and the current structure in WG draft are satisfying the requirement of flexi-grid FWK draft (the info model in Fig. 17). We only need to deal with some differences in representation format, and some additional information may be useful.


1)      Different slice spacing is applicable but may not be necessary; the spirit to introduce flexible grid is to allow flexibility in spectrum allocation and current WG draft can satisfy the requirement. Not much further advantage for using slice spacing;

2)      Priority bits: I agree that it is widely used, I am basically fine to include priority bits in the sub-TLV. My only concern is, there are also such priority information in other place (for example OTN BW sub-TLV in Section 4.1.3 in RFC7138), do we need to repeat here? What is the relationship if we have two priorities? Is it possible the OTN priority is not consistent with flexi-grid priority? Why? And How to deal with this?

3)      Agreed, will change both the min/max widths to 16-bit in the next version;

4)      Personally I don¡¯t think it¡¯s necessary to change the current WG draft: I think your proposed representation can have equivalent result as the one in current WG draft;

Rajan, please correct me if there is misunderstanding, also let me know if you have other comments.

All, please feel free to comments, or we move to the list if necessary:)

Best wishes,
Haomian

·¢¼þÈË: Rajan Rao [mailto:rrao@infinera.com]
·¢ËÍʱ¼ä: 2015Äê2ÔÂ24ÈÕ 4:03
ÊÕ¼þÈË: Zhenghaomian; Fatai Zhang
³­ËÍ: Khuzema Pithewan; Iftekhar Hussain
Ö÷Ìâ: RE: [CCAMP] ת·¢: I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Haomian,

The Flexgrid FWK doc has been updated with reference to RFC4202.   This should address the comment you had in the earlier email.  Pl refer to updated doc (attached email from Ramon).  Pl let us know how you would like to proceed.

FWK doc Snip below:

5.1.2.  Routing

   The routing protocol will support all functions as described in
   [RFC4202] and extend them to a flexi-grid data plane.

Thx
Rajan

From: Rajan Rao
Sent: Tuesday, February 03, 2015 2:28 PM
To: Zhenghaomian; Fatai Zhang
Cc: Khuzema Pithewan; Iftekhar Hussain
Subject: RE: [CCAMP] ת·¢: I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt


Haomian,



Thx for the reply. Pl see below.



-----Original Message-----
From: Zhenghaomian [mailto:zhenghaomian@huawei.com]
Sent: Monday, February 02, 2015 11:22 PM
To: Rajan Rao; Fatai Zhang
Cc: Khuzema Pithewan; Iftekhar Hussain
Subject: ´ð¸´: [CCAMP] ת·¢: I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt



Hi, Rajan,



Firstly sorry for the very late response.



For your first concern, I see some difference in TLVs about priority issue (Table I in your draft). I think I understand your description but I didn't find very much advantage to include such 'scalable' settings.



RR>> Priority based advertisement is pretty standard mechanism used in all existing RFCs.  For e.g. you can find these in WSON, OTN  docs and any other Te-extensions draft.



Another concern from me is, for the flexi-grid literature, there are more than one WG draft, I think it's better to consider such case in fwk draft, and after that the OSPF one can revise accordingly. P.S, I don't know whether this topic was discussed on the list before (perhaps there are some conclusions, let me know). If not, I would like to suggest move to the list.



RR>> I looked at framework.  Yes, it doesn¡¯t talk about priority based advertisement.  Thanks for pointing this out. Good catch. We will provide this comment to FWK authors & CC you.  I do not see any issue updating the fwk doc with this detail.



For your second concern on Max LSP Bandwidth, my understanding is you are trying to use the description in section 3.2 of your draft to replace the one in section 4.3 of current WG draft. Is this true? I believe the description in your draft is clear and correct. BTW, I noticed bit difference in Min Bandwidth (16 bits allocated in your draft and 8 bit in current WG draft), hopefully this will not be a big issue (8 bit support a bandwidth up to 3200GHz, which is absolutely more than the normal requirement for a minimal BW).



RR>>  Yes, I was referring to section 3.2 in our draft.

We went with 16-bit fields for Min & Max fields as the values for these fields range from 0 ¨C 384.  We tried to address the case of using full spectrum BW as one LSP.  This is an extreme case but can¡¯t be ruled out.



Pl let me know if you have any other comments.

Thanks.



Best wishes,

Haomian



-----ÓʼþÔ­¼þ-----

·¢¼þÈË: Rajan Rao [mailto:rrao@infinera.com]

·¢ËÍʱ¼ä: 2014Äê12ÔÂ18ÈÕ 6:09

ÊÕ¼þÈË: Zhenghaomian; Fatai Zhang

³­ËÍ: Khuzema Pithewan; Iftekhar Hussain

Ö÷Ìâ: RE: [CCAMP] ת·¢: I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt



Haomian,



As I had mentioned we are no longer pushing for SuperChannel in the draft.  So, this should make it easier to merge the docs.



In my view there are couple of areas your draft doesn't address which can be taken from our draft:



1.  You have separated Max & Min Slot width in Port Label restriction sub-TLV.  This is O.K. But this doesn't allow for priority based Min/Max usage.   Our draft allows for this flexibility which can be used.

2.  Max LSP Bandwidth field definition can be taken from our doc.



The priority handling can be further simplified by merging slice info & Min/Max fields in to a single sub-TLV if other authors agree.



Pl let me know.



Thx

Rajan



-----Original Message-----

From: Zhenghaomian [mailto:zhenghaomian@huawei.com]

Sent: Tuesday, December 16, 2014 5:15 PM

To: Rajan Rao; Fatai Zhang

Cc: Khuzema Pithewan

Subject: ´ð¸´: [CCAMP] ת·¢: I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt



Hi, Rajan and Khuzema,



Thanks for reminding. Do you guys have any suggestion on how to merge? Even if we think the current draft is self-contained, we are still open on this.



I know there are some different ideas from Infinera, but sorry I am not fully understand every detail. Please let me know the exact section that need to be updated and let's see how to proceed. Again, this will finally be determined by the WG since already adopted.



Thanks.



Best wishes,

Haomian



-----ÓʼþÔ­¼þ-----

·¢¼þÈË: Rajan Rao [mailto:rrao@infinera.com]

·¢ËÍʱ¼ä: 2014Äê12ÔÂ17ÈÕ 6:01

ÊÕ¼þÈË: Zhenghaomian; Fatai Zhang

³­ËÍ: Khuzema Pithewan

Ö÷Ìâ: RE: [CCAMP] ת·¢: I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt



Haomian,



We had sent couple of emails asking about merging the contents with our draft.  Do you see an opportunity or any issues with the merge?  Can you pl respond on how you would like to proceed? Pl see the attached email we had sent a while back.





Thanks

Rajan



-----Original Message-----

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Zhenghaomian

Sent: Tuesday, December 16, 2014 12:24 AM

To: ccamp@ietf.org<mailto:ccamp@ietf.org>

Subject: [CCAMP] ת·¢: I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt



Dear CCAMPers,



We upload an updated version to reactivate the following draft against expiration, together updating the Max width issue proposed in previous discussions. Your comments are highly welcomed, thanks.



Best wishes,

Haomian on behalf of authors



-----ÓʼþÔ­¼þ-----

·¢¼þÈË: CCAMP [mailto:ccamp-bounces@ietf.org] ´ú±í internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>

·¢ËÍʱ¼ä: 2014Äê12ÔÂ16ÈÕ 16:16

ÊÕ¼þÈË: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>

³­ËÍ: ccamp@ietf.org<mailto:ccamp@ietf.org>

Ö÷Ìâ: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.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           : GMPLS OSPF-TE Extensions in support of Flexible Grid

        Authors         : Xian Zhang

                          Haomian Zheng

                          Ramon Casellas

                          Oscar Gonzalez de Dios

                          Daniele Ceccarelli

               Filename        : draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

               Pages           : 14

               Date            : 2014-12-16



Abstract:

   This memo describes the OSPF-TE extensions in support of GMPLS

   control of networks that include devices that use the new flexible

   optical grid.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexible-grid-ospf-ext/



There's also a htmlized version available at:

http://tools.ietf.org/html/draft-ietf-ccamp-flexible-grid-ospf-ext-01



A diff from the previous version is available at:

http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-flexible-grid-ospf-ext-01





Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

CCAMP mailing list

CCAMP@ietf.org<mailto:CCAMP@ietf.org>

https://www.ietf.org/mailman/listinfo/ccamp

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org<mailto:CCAMP@ietf.org>

https://www.ietf.org/mailman/listinfo/ccamp