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

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 3 Mar 2015 15:45:00 -0000

Hi,
 
[Speaking as a regular contributor which, praise be, I will in just three weeks'
time. Not that I'm counting...]
 
There is some up-levelling to be done here.
 
Rajan seems to be proposing a new concept that would allow us to advertise not
just the bandwidth available at each priority (per 4202) but also to vary the
constraints on allocation per priority. This would allow us to say that priority
x LSPs can only use chunks of bandwidth between sizes a and b, while priority y
LSPs can only chunks of bandwidth between sizes c and d.
 
I have three questions:
- Is this a valid thing to want to do in any technology?
- Is it something we want to do in Flexigrid?
- Is it something that should be generalised?
 
Thanks,
Adrian
 
From: CCAMP [mailto:[email-masked]] On Behalf Of Zhangxian (Xian)
Sent: 03 March 2015 07:22
To: Rajan Rao; CCAMP ([email-masked]); 'Ramon Casellas'
Cc: Iftekhar Hussain
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt
 
Hi, Rajan, 
 
From: Rajan Rao [mailto:[email-masked]] 
Sent: 2015年3月3日 8:56
To: Zhangxian (Xian); CCAMP ([email-masked]); 'Ramon Casellas'
Cc: Khuzema Pithewan; Iftekhar Hussain; Biao Lu
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt
 
Xian,
 
Minimum LSP bandwidth will address technological advances. For e.g. tomorrow’s
6.25GHz  instead of today’s 12.5GHz. GMPLS extensions should cover the case of
network having a mix of different hardware capabilities. 
[Xian]: I agree with the above statements. But they are a property of an
interface, which AFAIC does not change over time. That’s why I said it have
already be covered by Section 4.3 (please take a look if any information is
missing as well).  ISCD, especially SCSI is used to advertise the available
bandwidth information and it is changing dynamically. So, I do not think SCSI is
the right place to do so.
 
Advertising per priority aligns with RFC4202.  I don’t see any issues.
[Xian] I have to disagree.   RFC4202 does not support advertising min LSP
bandwidth per priority. Please take a look at the encoding of Section 1.4. of
RFC4203. What’s said there: for PSC and TDM, you carry ONE minimum LSP
bandwidth information (which is not associated per priority); for Lambda
switching, it does not have any SCSI at all. 
 
Having said all these, I personally do not think the value of advertising min
LSP bandwidth per priority. If you disagree again, could you give me an usage
example?  
 
As far as Maximum LSP bandwidth goes, either option would work but my preference
would be to put it in technology specific part (SCSI).
[Xian]: point taken. I agree with you that both work but I would prefer to take
Option 1. Let’s get a bit more feedback from the WG before updating the draft.
 
Regards,
Xian
 
Thx
Rajan
 
From: Zhangxian (Xian) [mailto:[email-masked]] 
Sent: Sunday, March 01, 2015 10:35 PM
To: Rajan Rao; CCAMP ([email-masked]); 'Ramon Casellas'
Cc: Khuzema Pithewan; Iftekhar Hussain; Biao Lu
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt
 
Hi, Rajan, all, 
 
      “Min & Max slot” you mentioned below is a bit mis-leading. I think you
wanted to say “Min & Max LSP bandwidth”. Let talk them one by one since we are
not aligned yet on both. 
      
      Why do we need to advertise Min LSP bandwidth per priority in ISCD, e.g.,
a request cannot set up a LSP smaller than X GHz and it varies per priority? If
you  meant to say the interface limitation, it is covered in Section 4.3
already.  
 
      As for the Max LSP bandwidth information, I agree with you that RFC4204
has this requirement. This draft (draft-ietf-ccamp-flexible-grid-ospf-ext-01)
needs to be updated to reflect this. I can think of two options: 
 
Option A: use the existing fields (MAX LSP Bandwidth at priority x, x=0-7)  in
the ISCD (defined in Section 1.4. of RFC4203). The point that we need to update
is the unit to be usable in the context of Flexi-grid. It will be Hz not byte
per second.
 
Option B: We add the max LSP bandwidth field (16 bit) in the Available Labels
Field by using the Reserved field.  
 
    Which option does the WG prefer?
 
Regards,
Xian
 
From: Rajan Rao [mailto:[email-masked]] 
Sent: 2015年2月28日 2:51
To: Zhangxian (Xian); CCAMP ([email-masked]); 'Ramon Casellas'
Cc: Khuzema Pithewan; Iftekhar Hussain; Biao Lu
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt
 
Xian, all
 
Section 4.3 is trying to use port label restrictions sub-TLV with a new
restriction type.  This is fine.  But how does a path computing node determine
if it can use the link to setup an LSP with N-slots @ priority ‘p’?   For e.g
I don’t want to allow priority 7 LSPs to use bandwidth greater than 20 slots on
the link but allow for LSPs with priority 0, 1 & 2.  Where is this info in the
TLV?
 
We had given examples when we presented our draft in Taipei IETF-82.  Ref slides
8 & 10 (link below).  We had coverage for advertisement of  Min & Max slot
widths per priority. This is meant to align with RFC 4202.  I believe WG doc
lacks this and needs to address.
http://www.ietf.org/proceedings/82/slides/ccamp-18.pdf
 
thx
Rajan
From: Zhangxian (Xian) [mailto:[email-masked]] 
Sent: Thursday, February 26, 2015 5:33 PM
To: Rajan Rao; CCAMP ([email-masked]); 'Ramon Casellas'
Cc: Khuzema Pithewan; Iftekhar Hussain; Biao Lu
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt
 
Hi, Rajan and all,
 
Thank you for your clarification and I now fully understand your question. I
think you have misunderstood Section 4.3. of this draft. It was not to describe
dynamic Max & Min LSP bandwidth but rather the capability/constraint associated
with an port, which rarely change over time.
 
Isn’t information per priority already supported? Quoting text from the drafts
referred:
 
“The technology specific part of the WSON ISCD may include a variable
   number of sub-TLVs called Bandwidth sub-TLVs.”
 
As for the Mix and Max LSP bandwidth, could you give me an example of what you
said below, i.e.,“Availability of  ‘N’ consecutive labels doesn’t mean you
can setup an LSP with a size of ‘N’”? 
 
    What does the WG think of the issue under discussion?
 
Regards,
Xian

From: Rajan Rao [mailto:[email-masked]] 
Sent: 2015年2月27日 4:03
To: Zhangxian (Xian); CCAMP ([email-masked]); 'Ramon Casellas'
Cc: Khuzema Pithewan; Iftekhar Hussain; Biao Lu
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt
 
Xian,
 
I understand this doc is trying to reuse GEN-ENCODE & there is support for
priority.  I am not referring to this one.  The Min Width & Max  Width fields do
exist in the draft but these alone are not sufficient. We need info per priority
for the following reason.
 
The intent of Min & Max width info is to specify what is the Minimum/Maximum LSP
bandwidth an LSP could reserve at a given priority ‘p’ on the link.  You can
draw parallel to ‘Minimum LSP Bandwidth’ & ‘Maximum LSP Bandwidth’ fields in
RFC 4202.   
 
I don’t understand how you can derive this from label set field.   Availability
of  ‘N’ consecutive labels doesn’t mean you can setup an LSP with a size of
‘N’.  
 
Thx
Rajan

From: Zhangxian (Xian) [mailto:[email-masked]] 
Sent: Wednesday, February 25, 2015 5:37 PM
To: Rajan Rao; CCAMP ([email-masked]); 'Ramon Casellas'
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt
 
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:[email-masked]] 
Sent: 2015年2月26日 7:17
To: Daniele Ceccarelli; Zhenghaomian; Fatai Zhang; CCAMP ([email-masked])
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:[email-masked]] 
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:[email-masked]] 
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 – up to 8
2.       Min/Max slot width field – 16 bit instead of 8  (I see you are
agreeing to this change below)
3.       Max LSP Bandwidth – this was debated in previous meetings but no firm
conclusion. 
  
Thx
Rajan
 
From: Zhenghaomian [mailto:[email-masked]] 
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 commentsJ  
 
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 necessaryJ
 
Best wishes,
Haomian
 
发件人: Rajan Rao [mailto:[email-masked]] 
发送时间: 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:[email-masked]] 
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 – 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:[email-masked]> mailto:[email-masked]] 
发送时间: 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:[email-masked]>
mailto:[email-masked]] 
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:[email-masked]> mailto:[email-masked]] 
发送时间: 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:[email-masked]> mailto:[email-masked]] On
Behalf Of Zhenghaomian
Sent: Tuesday, December 16, 2014 12:24 AM
To:  <mailto:[email-masked]> [email-masked]
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:[email-masked]> mailto:[email-masked]]
代表  <mailto:[email-masked]> [email-masked]
发送时间: 2014年12月16日 16:16
收件人:  <mailto:[email-masked]> [email-masked]
抄送:  <mailto:[email-masked]> [email-masked]
主题: [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/>
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>
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>
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/> ftp://ftp.ietf.org/internet-drafts/
 
_______________________________________________
CCAMP mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/ccamp>
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/ccamp>
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Rajan Rao <[email-masked]>
Date: Wed, 4 Mar 2015 01:11:54 +0000

Adrian,

Looks like there is different interpretation of RFC 4202 text.  RFC 4202 text in sections 2.4.2 & 2.4.3  says

“…..an LSP at priority
  p could reserve any bandwidth between the Minimum LSP Bandwidth and
   the Maximum LSP Bandwidth at priority p, provided that the bandwidth…..”

Having only the Maximum LSP bandwidth field priority based & not the Minimum LSP bandwidth field doesn’t seem right.  It is a simplification for sure.  What is the correct interpretation of above text?  Will be good to know.

Thx
Rajan

From: Adrian Farrel [mailto:[email-masked]]
Sent: Tuesday, March 03, 2015 7:45 AM
To: 'Zhangxian (Xian)'; Rajan Rao; 'CCAMP'; 'Ramon Casellas'
Cc: Iftekhar Hussain
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Hi,

[Speaking as a regular contributor which, praise be, I will in just three weeks' time. Not that I'm counting...]

Rajan seems to be proposing a new concept that would allow us to advertise not just the bandwidth available at each priority (per 4202) but also to vary the constraints on allocation per priority. This would allow us to say that priority x LSPs can only use chunks of bandwidth between sizes a and b, while priority y LSPs can only chunks of bandwidth between sizes c and d.

I have three questions:

Thanks,
Adrian

From: CCAMP [mailto:[email-masked]] On Behalf Of Zhangxian (Xian)
Sent: 03 March 2015 07:22
To: Rajan Rao; CCAMP ([email-masked]<mailto:[email-masked]>); 'Ramon Casellas'
Cc: Iftekhar Hussain
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Hi, Rajan,

From: Rajan Rao [mailto:[email-masked]]
Sent: 2015年3月3日 8:56
To: Zhangxian (Xian); CCAMP ([email-masked]<mailto:[email-masked]>); 'Ramon Casellas'
Cc: Khuzema Pithewan; Iftekhar Hussain; Biao Lu
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Xian,

Minimum LSP bandwidth will address technological advances. For e.g. tomorrow’s 6.25GHz  instead of today’s 12.5GHz. GMPLS extensions should cover the case of network having a mix of different hardware capabilities.
[Xian]: I agree with the above statements. But they are a property of an interface, which AFAIC does not change over time. That’s why I said it have already be covered by Section 4.3 (please take a look if any information is missing as well).  ISCD, especially SCSI is used to advertise the available bandwidth information and it is changing dynamically. So, I do not think SCSI is the right place to do so.

Advertising per priority aligns with RFC4202.  I don’t see any issues.
[Xian] I have to disagree.   RFC4202 does not support advertising min LSP bandwidth per priority. Please take a look at the encoding of Section 1.4. of RFC4203. What’s said there: for PSC and TDM, you carry ONE minimum LSP bandwidth information (which is not associated per priority); for Lambda switching, it does not have any SCSI at all.

Having said all these, I personally do not think the value of advertising min LSP bandwidth per priority. If you disagree again, could you give me an usage example?

As far as Maximum LSP bandwidth goes, either option would work but my preference would be to put it in technology specific part (SCSI).
[Xian]: point taken. I agree with you that both work but I would prefer to take Option 1. Let’s get a bit more feedback from the WG before updating the draft.

Regards,
Xian

Thx
Rajan

To: Rajan Rao; CCAMP ([email-masked]<mailto:[email-masked]>); 'Ramon Casellas'

Hi, Rajan, all,

      “Min & Max slot” you mentioned below is a bit mis-leading. I think you wanted to say “Min & Max LSP bandwidth”. Let talk them one by one since we are not aligned yet on both.

      Why do we need to advertise Min LSP bandwidth per priority in ISCD, e.g., a request cannot set up a LSP smaller than X GHz and it varies per priority? If you  meant to say the interface limitation, it is covered in Section 4.3 already.

      As for the Max LSP bandwidth information, I agree with you that RFC4204 has this requirement. This draft (draft-ietf-ccamp-flexible-grid-ospf-ext-01) needs to be updated to reflect this. I can think of two options:

Option A: use the existing fields (MAX LSP Bandwidth at priority x, x=0-7)  in the ISCD (defined in Section 1.4. of RFC4203). The point that we need to update is the unit to be usable in the context of Flexi-grid. It will be Hz not byte per second.

Option B: We add the max LSP bandwidth field (16 bit) in the Available Labels Field by using the Reserved field.

Regards,
Xian

From: Rajan Rao [mailto:[email-masked]]
Sent: 2015年2月28日 2:51
To: Zhangxian (Xian); CCAMP ([email-masked]<mailto:[email-masked]>); 'Ramon Casellas'
Cc: Khuzema Pithewan; Iftekhar Hussain; Biao Lu
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Xian, all

Section 4.3 is trying to use port label restrictions sub-TLV with a new restriction type.  This is fine.  But how does a path computing node determine if it can use the link to setup an LSP with N-slots @ priority ‘p’?   For e.g  I don’t want to allow priority 7 LSPs to use bandwidth greater than 20 slots on the link but allow for LSPs with priority 0, 1 & 2.  Where is this info in the TLV?

We had given examples when we presented our draft in Taipei IETF-82.  Ref slides 8 & 10 (link below).  We had coverage for advertisement of  Min & Max slot widths per priority. This is meant to align with RFC 4202.  I believe WG doc lacks this and needs to address.
http://www.ietf.org/proceedings/82/slides/ccamp-18.pdf

thx
Rajan
To: Rajan Rao; CCAMP ([email-masked]<mailto:[email-masked]>); 'Ramon Casellas'

Hi, Rajan and all,

Thank you for your clarification and I now fully understand your question. I think you have misunderstood Section 4.3. of this draft. It was not to describe dynamic Max & Min LSP bandwidth but rather the capability/constraint associated with an port, which rarely change over time.

Isn’t information per priority already supported? Quoting text from the drafts referred:

As for the Mix and Max LSP bandwidth, could you give me an example of what you said below, i.e.,“Availability of  ‘N’ consecutive labels doesn’t mean you can setup an LSP with a size of ‘N’”?

Regards,
Xian

From: Rajan Rao [mailto:[email-masked]]
Sent: 2015年2月27日 4:03
To: Zhangxian (Xian); CCAMP ([email-masked]<mailto:[email-masked]>); 'Ramon Casellas'
Cc: Khuzema Pithewan; Iftekhar Hussain; Biao Lu
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Xian,

I understand this doc is trying to reuse GEN-ENCODE & there is support for priority.  I am not referring to this one.  The Min Width & Max  Width fields do exist in the draft but these alone are not sufficient. We need info per priority for the following reason.

The intent of Min & Max width info is to specify what is the Minimum/Maximum LSP bandwidth an LSP could reserve at a given priority ‘p’ on the link.  You can draw parallel to ‘Minimum LSP Bandwidth’ & ‘Maximum LSP Bandwidth’ fields in RFC 4202.

I don’t understand how you can derive this from label set field.   Availability of  ‘N’ consecutive labels doesn’t mean you can setup an LSP with a size of ‘N’.

Thx
Rajan

From: Zhangxian (Xian) [mailto:[email-masked]]
Sent: Wednesday, February 25, 2015 5:37 PM
To: Rajan Rao; CCAMP ([email-masked]<mailto:[email-masked]>); 'Ramon Casellas'
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

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:

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

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:[email-masked]]
Sent: 2015年2月26日 7:17
To: Daniele Ceccarelli; Zhenghaomian; Fatai Zhang; CCAMP ([email-masked]<mailto:[email-masked]>)
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,

Thx
Rajan

From: Daniele Ceccarelli [mailto:[email-masked]]
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:[email-masked]]
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.

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

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

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

Thx
Rajan

From: Zhenghaomian [mailto:[email-masked]]
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

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,

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:[email-masked]]
发送时间: 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

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,

-----Original Message-----
From: Zhenghaomian [mailto:[email-masked]]
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,

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).

We went with 16-bit fields for Min & Max fields as the values for these fields range from 0 – 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.

Thanks.

Best wishes,

Haomian

-----邮件原件-----

发送时间: 2014年12月18日 6:09

主题: 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.

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-----

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

-----邮件原件-----

发送时间: 2014年12月17日 6:01

抄送: 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:[email-masked]] On Behalf Of Zhenghaomian

To: [email-masked]<mailto:[email-masked]>

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,

-----邮件原件-----

发件人: CCAMP [mailto:[email-masked]] 代表 [email-masked]<mailto:[email-masked]>

发送时间: 2014年12月16日 16:16

收件人: [email-masked]<mailto:[email-masked]>

抄送: [email-masked]<mailto:[email-masked]>

This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

        Authors         : Xian Zhang

                          Haomian Zheng

                          Ramon Casellas

                          Oscar Gonzalez de Dios

                          Daniele Ceccarelli

               Pages           : 14

               Date            : 2014-12-16

Abstract:

   optical grid.

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.

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

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Wed, 4 Mar 2015 01:37:13 +0000

Hi, Rajan, all,

RFC4202 alone is indeed subject to your interpretation since it describes the requirements in text. RFC4203 (the OSPF extensions) & RFC5307 (IS-IS one) are much more clear as they defines the fields/encoding, matching what is described in RFC4202.

My 2cents,
Xian

From: Rajan Rao [mailto:[email-masked]]
Sent: 2015年3月4日 9:12
To: [email-masked]; Zhangxian (Xian); 'CCAMP'; 'Ramon Casellas'
Cc: Iftekhar Hussain
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Adrian,

“…..an LSP at priority

Thx
Rajan

Hi,

I have three questions:

Thanks,
Adrian

Hi, Rajan,

Xian,

Regards,
Xian

Thx
Rajan

Hi, Rajan, all,

Regards,
Xian

Xian, all

thx
Rajan

Hi, Rajan and all,

Regards,
Xian

Xian,

Thx
Rajan

Hi, Rajan,

Cheers,
Xian

Daniele,

Thx
Rajan

Hi all,

BR
Daniele

Haomian,

Thx
Rajan

Hi, Rajan,

  0                   1                   2                   3

In your proposal,

Best wishes,
Haomian

Haomian,

FWK doc Snip below:

5.1.2.  Routing

Thx
Rajan

From: Rajan Rao

Haomian,

-----Original Message-----
From: Zhenghaomian [mailto:[email-masked]]
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,

Thanks.

Best wishes,

Haomian

-----邮件原件-----

发送时间: 2014年12月18日 6:09

Haomian,

Pl let me know.

Thx

Rajan

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

Cc: Khuzema Pithewan

Hi, Rajan and Khuzema,

Thanks.

Best wishes,

Haomian

-----邮件原件-----

发送时间: 2014年12月17日 6:01

抄送: Khuzema Pithewan

Haomian,

Thanks

Rajan

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

Dear CCAMPers,

Best wishes,

-----邮件原件-----

发送时间: 2014年12月16日 16:16

        Authors         : Xian Zhang

                          Haomian Zheng

                          Ramon Casellas

                          Oscar Gonzalez de Dios

                          Daniele Ceccarelli

               Pages           : 14

               Date            : 2014-12-16

Abstract:

   optical grid.

CCAMP mailing list

CCAMP mailing list

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 4 Mar 2015 07:41:33 +0000

Hi Rajan,

What you quoted from RFC4202 is specific for TDM (e.g., SDH), and you can see there is no “Minimum LSP Bandwidth” defined for the GMPLS protocol even for TDM, because “Minimum LSP Bandwidth” is implicit and no need to carry this info in the protocol.

Does this make sense?

Best Regards

Fatai

From: CCAMP [mailto:[email-masked]] On Behalf Of Zhangxian (Xian)
Sent: Wednesday, March 04, 2015 9:37 AM
To: Rajan Rao; [email-masked]; 'CCAMP'; 'Ramon Casellas'
Cc: Iftekhar Hussain
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Hi, Rajan, all,

My 2cents,
Xian

From: Rajan Rao [mailto:[email-masked]]
Sent: 2015年3月4日 9:12
To: [email-masked]<mailto:[email-masked]>; Zhangxian (Xian); 'CCAMP'; 'Ramon Casellas'
Cc: Iftekhar Hussain
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Adrian,

“…..an LSP at priority

Thx
Rajan

Hi,

I have three questions:

Thanks,
Adrian

Hi, Rajan,

Xian,

Regards,
Xian

Thx
Rajan

Hi, Rajan, all,

Regards,
Xian

Xian, all

thx
Rajan

Hi, Rajan and all,

Regards,
Xian

Xian,

Thx
Rajan

Hi, Rajan,

Cheers,
Xian

Daniele,

Thx
Rajan

Hi all,

BR
Daniele

Haomian,

Thx
Rajan

Hi, Rajan,

  0                   1                   2                   3

In your proposal,

Best wishes,
Haomian

Haomian,

FWK doc Snip below:

5.1.2.  Routing

Thx
Rajan

From: Rajan Rao

Haomian,

-----Original Message-----
From: Zhenghaomian [mailto:[email-masked]]
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,

Thanks.

Best wishes,

Haomian

-----邮件原件-----

发送时间: 2014年12月18日 6:09

Haomian,

Pl let me know.

Thx

Rajan

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

Cc: Khuzema Pithewan

Hi, Rajan and Khuzema,

Thanks.

Best wishes,

Haomian

-----邮件原件-----

发送时间: 2014年12月17日 6:01

抄送: Khuzema Pithewan

Haomian,

Thanks

Rajan

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

Dear CCAMPers,

Best wishes,

-----邮件原件-----

发送时间: 2014年12月16日 16:16

        Authors         : Xian Zhang

                          Haomian Zheng

                          Ramon Casellas

                          Oscar Gonzalez de Dios

                          Daniele Ceccarelli

               Pages           : 14

               Date            : 2014-12-16

Abstract:

   optical grid.

CCAMP mailing list

CCAMP mailing list

---

From: [email-masked]
Date: Wed, 4 Mar 2015 17:11:48 +0800

Rajan,

Can you give us a detailed example about the use of "Minimum LSP 
bandwidth"?
Currently, I can not feel the importance of this information.

I like Ramon's answer: "It may be short-sighted to discard the option", so 
please go on.

Thanks
Qilei

Rajan Rao <[email-masked]> 
发件人:  "CCAMP" <[email-masked]>
2015-03-04 09:11

收件人
"[email-masked]" <[email-masked]>, "'Zhangxian (Xian)'" 
<[email-masked]>, 'CCAMP' <[email-masked]>, 'Ramon Casellas' 
<[email-masked]>, 
抄送
Iftekhar Hussain <[email-masked]>
主题
Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Adrian,
 
Looks like there is different interpretation of RFC 4202 text.  RFC 4202 
text in sections 2.4.2 & 2.4.3  says 
“…..an LSP at priority
  p could reserve any bandwidth between the Minimum LSP Bandwidth and
   the Maximum LSP Bandwidth at priority p, provided that the bandwidth…
..”
 
Having only the Maximum LSP bandwidth field priority based & not the 
Minimum LSP bandwidth field doesn’t seem right.  It is a simplification 
for sure.  What is the correct interpretation of above text?  Will be good 
to know. 
 
Thx
Rajan
 
Subject: RE: [CCAMP] I-D Action: 
 
Hi,
 
[Speaking as a regular contributor which, praise be, I will in just three 
weeks' time. Not that I'm counting...]

Rajan seems to be proposing a new concept that would allow us to advertise 
not just the bandwidth available at each priority (per 4202) but also to 
vary the constraints on allocation per priority. This would allow us to 
say that priority x LSPs can only use chunks of bandwidth between sizes a 
and b, while priority y LSPs can only chunks of bandwidth between sizes c 
and d.
 
I have three questions:
 
Thanks,
Adrian
 
Subject: Re: [CCAMP] I-D Action: 
 
Hi, Rajan, 
 
Subject: RE: [CCAMP] I-D Action: 
 
Xian,
 
Minimum LSP bandwidth will address technological advances. For e.g. 
tomorrow’s 6.25GHz  instead of today’s 12.5GHz. GMPLS extensions should 
cover the case of network having a mix of different hardware capabilities. 

[Xian]: I agree with the above statements. But they are a property of an 
interface, which AFAIC does not change over time. That’s why I said it 
have already be covered by Section 4.3 (please take a look if any 
information is missing as well).  ISCD, especially SCSI is used to 
advertise the available bandwidth information and it is changing 
dynamically. So, I do not think SCSI is the right place to do so.
 
Advertising per priority aligns with RFC4202.  I don’t see any issues.
[Xian] I have to disagree.   RFC4202 does not support advertising min LSP 
bandwidth per priority. Please take a look at the encoding of Section 1.4. 
of RFC4203. What’s said there: for PSC and TDM, you carry ONE minimum LSP 
bandwidth information (which is not associated per priority); for Lambda 
switching, it does not have any SCSI at all. 
 
Having said all these, I personally do not think the value of advertising 
min LSP bandwidth per priority. If you disagree again, could you give me 
an usage example? 
 
As far as Maximum LSP bandwidth goes, either option would work but my 
preference would be to put it in technology specific part (SCSI).
[Xian]: point taken. I agree with you that both work but I would prefer to 
take Option 1. Let’s get a bit more feedback from the WG before updating 
the draft.
 
Regards,
Xian
 
Thx
Rajan
 
Subject: RE: [CCAMP] I-D Action: 
 
Hi, Rajan, all, 
 
      “Min & Max slot” you mentioned below is a bit mis-leading. I think 
you wanted to say “Min & Max LSP bandwidth”. Let talk them one by one 
since we are not aligned yet on both. 
 
      Why do we need to advertise Min LSP bandwidth per priority in ISCD, 
e.g., a request cannot set up a LSP smaller than X GHz and it varies per 
priority? If you  meant to say the interface limitation, it is covered in 
Section 4.3 already. 
 
      As for the Max LSP bandwidth information, I agree with you that 
RFC4204 has this requirement. This draft 
(draft-ietf-ccamp-flexible-grid-ospf-ext-01) needs to be updated to 
reflect this. I can think of two options: 
 
Option A: use the existing fields (MAX LSP Bandwidth at priority x, x=0-7) 
 in the ISCD (defined in Section 1.4. of RFC4203). The point that we need 
to update is the unit to be usable in the context of Flexi-grid. It will 
be Hz not byte per second.
 
Option B: We add the max LSP bandwidth field (16 bit) in the Available 
Labels Field by using the Reserved field. 

Regards,
Xian
 
Subject: RE: [CCAMP] I-D Action: 
 
Xian, all
 
Section 4.3 is trying to use port label restrictions sub-TLV with a new 
restriction type.  This is fine.  But how does a path computing node 
determine if it can use the link to setup an LSP with N-slots @ priority 
‘p’?   For e.g  I don’t want to allow priority 7 LSPs to use bandwidth 
greater than 20 slots on the link but allow for LSPs with priority 0, 1 & 
2.  Where is this info in the TLV?
 
We had given examples when we presented our draft in Taipei IETF-82.  Ref 
slides 8 & 10 (link below).  We had coverage for advertisement of  Min & 
Max slot widths per priority. This is meant to align with RFC 4202.  I 
believe WG doc lacks this and needs to address.
http://www.ietf.org/proceedings/82/slides/ccamp-18.pdf
 
thx
Rajan
Subject: RE: [CCAMP] I-D Action: 
 
Hi, Rajan and all,
 
Thank you for your clarification and I now fully understand your question. 
I think you have misunderstood Section 4.3. of this draft. It was not to 
describe dynamic Max & Min LSP bandwidth but rather the 
capability/constraint associated with an port, which rarely change over 
time.
 
Isn’t information per priority already supported? Quoting text from the 
drafts referred:

As for the Mix and Max LSP bandwidth, could you give me an example of what 
you said below, i.e.,“Availability of  ‘N’ consecutive labels doesn’t 
mean you can setup an LSP with a size of ‘N’”? 

Regards,
Xian

Subject: RE: [CCAMP] I-D Action: 
 
Xian,
 
I understand this doc is trying to reuse GEN-ENCODE & there is support for 
priority.  I am not referring to this one.  The Min Width & Max  Width 
fields do exist in the draft but these alone are not sufficient. We need 
info per priority for the following reason.
 
The intent of Min & Max width info is to specify what is the 
Minimum/Maximum LSP bandwidth an LSP could reserve at a given priority ‘p
’ on the link.  You can draw parallel to ‘Minimum LSP Bandwidth’ & ‘
Maximum LSP Bandwidth’ fields in RFC 4202. 
 
I don’t understand how you can derive this from label set field. 
Availability of  ‘N’ consecutive labels doesn’t mean you can setup an 
LSP with a size of ‘N’. 
 
Thx
Rajan

Subject: RE: [CCAMP] I-D Action: 
 
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; 

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
 
Cc: Khuzema Pithewan; Iftekhar Hussain; Zhangxian (Xian); Ramon Casellas; 
 
Daniele,

Thx
Rajan 
 
Cc: Khuzema Pithewan; Iftekhar Hussain; Zhangxian (Xian); Ramon Casellas; 
 
Hi all,

BR
Daniele
 
From: Rajan Rao [mailto:[email-masked]] 
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 – up to 8
2.      Min/Max slot width field – 16 bit instead of 8  (I see you are 
agreeing to this change below)
3.      Max LSP Bandwidth – this was debated in previous meetings but no 
firm conclusion. 
 
Thx
Rajan
 
From: Zhenghaomian [mailto:[email-masked]] 
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 
commentsJ 

  0                   1                   2                   3
 
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. 

Best wishes,
Haomian

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

Thx
Rajan
 
From: Rajan Rao 
 
Haomian,

-----Original Message-----
From: Zhenghaomian [mailto:[email-masked]] 
Sent: Monday, February 02, 2015 11:22 PM
To: Rajan Rao; Fatai Zhang
Cc: Khuzema Pithewan; Iftekhar Hussain
Subject: 答复: [CCAMP] 转发: I-D Action: 
 
Hi, Rajan,

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 – 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.

Best wishes,
Haomian
 
-----邮件原件-----
发件人: Rajan Rao [mailto:[email-masked]] 
发送时间: 2014年12月18日 6:09
收件人: Zhenghaomian; Fatai Zhang
抄送: Khuzema Pithewan; Iftekhar Hussain
主题: RE: [CCAMP] 转发: I-D Action: 
 
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:[email-masked]] 
Sent: Tuesday, December 16, 2014 5:15 PM
To: Rajan Rao; Fatai Zhang
Cc: Khuzema Pithewan
Subject: 答复: [CCAMP] 转发: I-D Action: 
 
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:[email-masked]] 
发送时间: 2014年12月17日 6:01
收件人: Zhenghaomian; Fatai Zhang
抄送: Khuzema Pithewan
主题: RE: [CCAMP] 转发: I-D Action: 
 
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:[email-masked]] On Behalf Of Zhenghaomian
Sent: Tuesday, December 16, 2014 12:24 AM
To: [email-masked]
Subject: [CCAMP] 转发: I-D Action: 
 
Dear CCAMPers,

Best wishes,
 
-----邮件原件-----
发件人: CCAMP [mailto:[email-masked]] 代表 
[email-masked]
发送时间: 2014年12月16日 16:16
收件人: [email-masked]
抄送: [email-masked]
主题: [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:

 

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.

[email-masked]
[email-masked]
[email-masked]

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 04 Mar 2015 10:30:06 +0100

El 04/03/2015 a las 2:11, Rajan Rao escribió:
> Minimum LSP bandwidth field doesn’t seem right.  It is a 
> simplification for sure.  What is the correct interpretation of above 
> text?  Will be good to know.
>

Rajan, all

It is a good question, and in my humble opinion, there are different 
things (echoing Adrian's questions):

i) Whether RFC4202 text could imply that Minimum LSP bandwidth is a 
function of priority (p)

ii) The need for a priority-dependent Minimum LSP bandwidth (and, in 
particular, for flexi-grid networks) in view of the requirements of 
preemption, resource usage, etc. This is to me the most important point.

iii) The actual encoding (in terms of "m" or Hz, in the ISCD SCSI ...)

For ii) it would be good to clearly agree on the requirement (let's 
stick to current in-force grid definitions). Personally, I see that 
higher priorities are allowed higher values of Max LSP bandwidth, but 
when would you need that a lower priority LSP is allowed a lower minimum 
value (or, similiarly, why would I constraint high priority LSPs to not 
use lower LSP bandwidths?). I have no objection to work on iii) if ii) 
is clear.

Although IMHO not critical, for i) It is my understanding that the 
minimum LSP bandwidth is unique across priorities, and only the Maximum 
LSP bandwidth depends on the priority. RFC4202
- An interface may have more than one Interface Switching Capability 
Descriptor.  This is used to handle interfaces that support multiple 
switching capabilities, for interfaces that have Max LSP Bandwidth 
values that differ by priority level, and for interfaces that support  
discrete bandwidths. // Only Max is mentioned
- For a simple (unbundled) link, the Maximum LSP Bandwidth at priority p 
is defined to be (...) // there is no such definition for minimum "at 
priority p".
- The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP could 
reserve // it does not mention "at priority p" and is ISCD specific.
- an LSP at  priority p could reserve any bandwidth (...) by the Minimum 
LSP Bandwidth and the Maximum LSP Bandwidth at priority p. // It is my 
understanding that Minimum LSP Bandwidth refers to the actual definition 
in point 2, i.e., bw(p) = [min_lsp_bw, max_lsp_bw(p)]
- Actual OSPF-TE extensions (e.g. for PSC) where min_lsp_bw is unique.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 4 Mar 2015 11:00:55 +0000

Ramon, Adrian, all,

I am wondering whether we’re mixing bandwidth and frequency (spectrum).

Adrian, is it correct to change your sentence into:
“This would allow us to say that priority x LSPs can only use chunks of frequency/spectrum between sizes a and b, while priority y LSPs can only chunks of frequency/spectrum between sizes c and d.” ?

My tentative replies to your questions (but I would like to see more replies)
>- Is this a valid thing to want to do in any technology?
[DC] At the time being I don’t see any applicability other than the WDM. Is there anything else this would apply to? microwave?!
- Is it something we want to do in Flexigrid?
[DC] I don’t have a strict opinion on this. It is adding complexity but I’m not sure if there is a requirement for it.
- Is it something that should be generalised?
[DC] as per question 1, is it applicable to anything else than WDM?

On the minimum LSP bandwidth (this time speaking about bandwidth) I agree with Fatai. It was only used in SDH to understand the hierarchy (i.e. every container between min bw and max bw is supported). It disappeared in OTN due to the explicit introduction of the hierarchy.

BR
Daniele

From: CCAMP [mailto:[email-masked]] On Behalf Of Ramon Casellas
Sent: mercoledì 4 marzo 2015 10:30
To: Rajan Rao; [email-masked]; 'Zhangxian (Xian)'; 'CCAMP'
Cc: Iftekhar Hussain
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

“…..an LSP at priority

Rajan, all

It is a good question, and in my humble opinion, there are different things (echoing Adrian's questions):

i) Whether RFC4202 text could imply that Minimum LSP bandwidth is a function of priority (p)

ii) The need for a priority-dependent Minimum LSP bandwidth (and, in particular, for flexi-grid networks) in view of the requirements of preemption, resource usage, etc. This is to me the most important point.

For ii) it would be good to clearly agree on the requirement (let's stick to current in-force grid definitions). Personally, I see that higher priorities are allowed higher values of Max LSP bandwidth, but when would you need that a lower priority LSP is allowed a lower minimum value (or, similiarly, why would I constraint high priority LSPs to not use lower LSP bandwidths?). I have no objection to work on iii) if ii) is clear.

Although IMHO not critical, for i) It is my understanding that the minimum LSP bandwidth is unique across priorities, and only the Maximum LSP bandwidth depends on the priority. RFC4202
- An interface may have more than one Interface Switching Capability Descriptor.  This is used to handle interfaces that support multiple switching capabilities, for interfaces that have Max LSP Bandwidth  values that differ by priority level, and for interfaces that support  discrete bandwidths. // Only Max is mentioned
- For a simple (unbundled) link, the Maximum LSP Bandwidth at priority p is defined to be (...) // there is no such definition for minimum "at priority p".
- The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP could reserve // it does not mention "at priority p" and is ISCD specific.
- an LSP at  priority p could reserve any bandwidth (...) by the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p. // It is my understanding that Minimum LSP Bandwidth refers to the actual definition in point 2, i.e., bw(p) = [min_lsp_bw, max_lsp_bw(p)]
- Actual OSPF-TE extensions (e.g. for PSC) where min_lsp_bw is unique.

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 04 Mar 2015 12:22:17 +0100

> I am wondering whether we’re mixing bandwidth and frequency (spectrum).
hi Daniele, all

It is my understanding (although through abuse of language it may seem 
otherwise) that the following was implied/implicit:  past discussions on 
flex-grid refer to the flexi-grid media layer, where the controlled 
resource is the optical spectrum, allocated in terms of frequency slot 
(widths) and with applicable units (Hz); that the use of the term 
"bandwidth" is to be taken in this context with a big grain of salt 
(i.e. no such concept directly applies given the a-priori-unknown 
modulation format spectral efficiency). IOW, when we were discussing 
about "bandwidth" be in terms of "Maximum LSP Bandwidth , Minimum LSP 
Bandwidth" (and referring to terms used in existing docs) -- the actual 
underlying "concept" still applies and related to e.g. TSPEC, FLOW in 
terms of "m"s. Sorry if it looked otherwise/confusing.

Maybe to avoid confusion it is worth to clearly state "Minimum LSP 
Frequency Slot Width" and "Maximum LSP Frequency Slot Width at priority p"
Thanks
Ramon

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 4 Mar 2015 11:53:45 +0000

Hi Ramon,

Yes, I think that was implicitly clear. BTW just to be sure, let’s call it frequency slot slot width, chunck of spectrum or water…just to make it explicit.

My point regards the quote of RFC4202 and RFC4203 where bandwidth means bandwidth and not portions of the spectrum.

Daniele

From: Ramon Casellas [mailto:[email-masked]]
Sent: mercoledì 4 marzo 2015 12:22
To: Daniele Ceccarelli; Rajan Rao; [email-masked]; 'Zhangxian (Xian)'; 'CCAMP'
Cc: Iftekhar Hussain
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

hi Daniele, all

It is my understanding (although through abuse of language it may seem otherwise) that the following was implied/implicit:  past discussions on flex-grid refer to the flexi-grid media layer, where the controlled resource is the optical spectrum, allocated in terms of frequency slot (widths) and with applicable units (Hz); that the use of the term "bandwidth" is to be taken in this context with a big grain of salt (i.e. no such concept directly applies given the a-priori-unknown modulation format spectral efficiency). IOW, when we were discussing about "bandwidth" be in terms of "Maximum LSP Bandwidth , Minimum LSP Bandwidth" (and referring to terms used in existing docs) -- the actual underlying "concept" still applies and related to e.g. TSPEC, FLOW in terms of "m"s. Sorry if it looked otherwise/confusing.

Maybe to avoid confusion it is worth to clearly state "Minimum LSP Frequency Slot Width" and "Maximum LSP Frequency Slot Width at priority p"
Thanks
Ramon

---

From: Lou Berger <[email-masked]>
Date: Wed, 04 Mar 2015 07:07:38 -0500

Daniele,

On 3/4/2015 6:53 AM, Daniele Ceccarelli wrote:
>
> Hi Ramon,
>
>  
>
> Yes, I think that was implicitly clear. BTW just to be sure, let’s
> call it frequency slot slot width, chunck of spectrum or water…just to
> make it explicit.
>
>  
>
> My point regards the quote of RFC4202 and RFC4203 where bandwidth
> means bandwidth and not portions of the spectrum.
>
>  
>

I'm not sure what you mean.  In the generic portion of the
advertisements defined in 4202/3, the available lambdas/timeslots/etc
(and perhaps now spectrum) have always been advertised as aggregate BW.  

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 4 Mar 2015 12:23:13 +0000

Hi Lou,

Section 2.4.4 of RFC4202 says:

   The additional information includes Reservable Bandwidth per
   priority, which specifies the bandwidth of an LSP that could be
   supported by the interface at a given priority number.

And 3.7, for example, says:

      Interface Switching Capability Descriptor:
         Interface Switching Capability = LSC
         Encoding = Lambda (photonic)
         Reservable Bandwidth = Determined by optical technology limits

It is all about the bitrate of a lambda, not the amount of spectrum that a lambda can take. I think these are two different dimensions on the problem. Aren't they?
I would say that RFC4202 comes into play when we speak about the signal layer rather than the media layer.

Daniele

> From: Lou Berger [mailto:[email-masked]]
> Sent: mercoledì 4 marzo 2015 13:08
> To: Daniele Ceccarelli; Ramon Casellas; Rajan Rao; [email-masked];
> 'Zhangxian (Xian)'; 'CCAMP'
> Cc: Iftekhar Hussain
> > Yes, I think that was implicitly clear. BTW just to be sure, let's
> > call it frequency slot slot width, chunck of spectrum or water.just to
> > make it explicit.
> >
> >
> >
> I'm not sure what you mean.  In the generic portion of the advertisements
> defined in 4202/3, the available lambdas/timeslots/etc (and perhaps now
> spectrum) have always been advertised as aggregate BW.
> 
> Lou
> 
> > Daniele
> >
>

---

From: Dieter Beller <[email-masked]>
Date: Wed, 4 Mar 2015 14:03:49 +0100

Hi all,

it looks like we fell into the bandwidth ambiguity trap - see:
http://en.wikipedia.org/wiki/Bandwidth_%28disambiguation%29

In the flex frid context we are certainly in the signal processing
("good old analog") world where bandwidth is measured in Hz.

When we talk about the bitrate of the digital  information carried
by a modulated optical carrier we are in the computing world

where bandwidth is measured in bit/s.

I hope this helps.

Thanks,

Dieter

On 04.03.2015 13:23, Daniele Ceccarelli
wrote:

Hi Lou,

Daniele

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: mercoledì 4 marzo 2015 13:08
To: Daniele Ceccarelli; Ramon Casellas; Rajan Rao; [email-masked];
'Zhangxian (Xian)'; 'CCAMP'
Cc: Iftekhar Hussain
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-
01.txt

Daniele,

Hi Ramon,

Lou

Daniele

---

From: Lou Berger <[email-masked]>
Date: Wed, 04 Mar 2015 08:12:15 -0500

> I would say that RFC4202 comes into play when we speak about the signal layer rather than the media layer.

I think we've been here before.  Consider the cases of waveband switches
or mems+awg, both of which switched/covered ranges of the spectrum...

Lou

---

From: Rajan Rao <[email-masked]>
Date: Wed, 4 Mar 2015 20:45:46 +0000

Fatai,

The text is not specific to TDM.  It is present in both PSC (section 2.4.2) and TDM (section 2.4.3) cases.

Thx
Rajan

From: Fatai Zhang [mailto:[email-masked]]
Sent: Tuesday, March 03, 2015 11:42 PM
To: Zhangxian (Xian); Rajan Rao; [email-masked]; 'CCAMP'; 'Ramon Casellas'
Cc: Iftekhar Hussain
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Hi Rajan,

Does this make sense?

Best Regards

Fatai

From: CCAMP [mailto:[email-masked]] On Behalf Of Zhangxian (Xian)
Sent: Wednesday, March 04, 2015 9:37 AM
To: Rajan Rao; [email-masked]<mailto:[email-masked]>; 'CCAMP'; 'Ramon Casellas'
Cc: Iftekhar Hussain
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Hi, Rajan, all,

My 2cents,
Xian

Adrian,

“…..an LSP at priority

Thx
Rajan

Hi,

I have three questions:

Thanks,
Adrian

Hi, Rajan,

Xian,

Regards,
Xian

Thx
Rajan

Hi, Rajan, all,

Regards,
Xian

Xian, all

thx
Rajan

Hi, Rajan and all,

Regards,
Xian

Xian,

Thx
Rajan

Hi, Rajan,

Cheers,
Xian

Daniele,

Thx
Rajan

Hi all,

BR
Daniele

Haomian,

Thx
Rajan

Hi, Rajan,

  0                   1                   2                   3

In your proposal,

Best wishes,
Haomian

Haomian,

FWK doc Snip below:

5.1.2.  Routing

Thx
Rajan

From: Rajan Rao

Haomian,

-----Original Message-----
From: Zhenghaomian [mailto:[email-masked]]
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,

Thanks.

Best wishes,

Haomian

-----邮件原件-----

发送时间: 2014年12月18日 6:09

Haomian,

Pl let me know.

Thx

Rajan

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

Cc: Khuzema Pithewan

Hi, Rajan and Khuzema,

Thanks.

Best wishes,

Haomian

-----邮件原件-----

发送时间: 2014年12月17日 6:01

抄送: Khuzema Pithewan

Haomian,

Thanks

Rajan

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

Dear CCAMPers,

Best wishes,

-----邮件原件-----

发送时间: 2014年12月16日 16:16

        Authors         : Xian Zhang

                          Haomian Zheng

                          Ramon Casellas

                          Oscar Gonzalez de Dios

                          Daniele Ceccarelli

               Pages           : 14

               Date            : 2014-12-16

Abstract:

   optical grid.

CCAMP mailing list

CCAMP mailing list

---

From: Rajan Rao <[email-masked]>
Date: Wed, 4 Mar 2015 20:55:03 +0000

Qilei,

I gave to technological advance e.g. earlier.  Here is a simple e.g. when you would need Min LSP BW info:

A-----B------C

Network A-B-C exists with 12.5GHz min granularity.   Today’s network

Introduce  C-D link which is 6.25GHz capable: Tomorrow’s network growth

A—B---C---D

D is computing path to A.  All it needs is 6.25GHz.   Links A-B and B-C don’t support this.   How will D know about this?

Hope this helps.    The discussion is around the need to advertise this info for each priority.
Regards
Rajan

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 04, 2015 1:12 AM
To: Rajan Rao
Cc: [email-masked]; 'CCAMP'; Iftekhar Hussain; 'Ramon Casellas'; 'Zhangxian (Xian)'
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Rajan,

Can you give us a detailed example about the use of "Minimum LSP bandwidth"?
Currently, I can not feel the importance of this information.

I like Ramon's answer: "It may be short-sighted to discard the option", so please go on.

Thanks
Qilei

Rajan Rao <[email-masked]<mailto:[email-masked]>>
发件人:  "CCAMP" <[email-masked]<mailto:[email-masked]>>

2015-03-04 09:11

收件人

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "'Zhangxian (Xian)'" <[email-masked]<mailto:[email-masked]>>, 'CCAMP' <[email-masked]<mailto:[email-masked]>>, 'Ramon Casellas' <[email-masked]<mailto:[email-masked]>>,

抄送

Iftekhar Hussain <[email-masked]<mailto:[email-masked]>>

主题

Adrian,

Thx
Rajan

Hi,

I have three questions:

Thanks,
Adrian

Hi, Rajan,

Xian,

Regards,
Xian

Thx
Rajan

Hi, Rajan, all,

Regards,
Xian

Xian, all

thx
Rajan

Hi, Rajan and all,

Regards,
Xian

Xian,

Thx
Rajan

Hi, Rajan,

Cheers,
Xian

Daniele,

Thx
Rajan

Hi all,

BR
Daniele

Haomian,

Thx
Rajan

Hi, Rajan,

  0                   1                   2                   3

In your proposal,

Best wishes,
Haomian

Haomian,

FWK doc Snip below:

5.1.2.  Routing

Thx
Rajan

From: Rajan Rao

Haomian,

-----Original Message-----
From: Zhenghaomian [mailto:[email-masked]]
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,

Best wishes,
Haomian

-----邮件原件-----
发件人: Rajan Rao [mailto:[email-masked]]
发送时间: 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,

Pl let me know.

Thx
Rajan

-----Original Message-----
From: Zhenghaomian [mailto:[email-masked]]
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.

Best wishes,
Haomian

-----邮件原件-----
发件人: Rajan Rao [mailto:[email-masked]]
发送时间: 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,

Thanks
Rajan

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Zhenghaomian
Sent: Tuesday, December 16, 2014 12:24 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [CCAMP] 转发: I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Dear CCAMPers,

Best wishes,

-----邮件原件-----
发件人: CCAMP [mailto:[email-masked]] 代表 [email-masked]<mailto:[email-masked]>
发送时间: 2014年12月16日 16:16
收件人: [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Abstract:

_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp

---

From: [email-masked]
Date: Thu, 5 Mar 2015 09:07:21 +0800

Rajan,

Sorry about this.  What I really wanted to express is how to use the Min 
LSP BW for each priority. Just from my opinion, it will be necessary to 
advertise the Min LSP BW priority info as long as you point out we SHOULD 
use it somewhere.

As this thread is talking about this, I think maybe an example would help 
understanding.

Thanks
Qilei

2015-03-05 04:55

收件人
"[email-masked]" <[email-masked]>, 
抄送
"[email-masked]" <[email-masked]>, 'CCAMP' <[email-masked]>, 
Iftekhar Hussain <[email-masked]>, 'Ramon Casellas' 
<[email-masked]>, "'Zhangxian (Xian)'" <[email-masked]>
主题
RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Qilei,
 
I gave to technological advance e.g. earlier.  Here is a simple e.g. when 
you would need Min LSP BW info:
 
A-----B------C 

 
A—B---C---D
 
D is computing path to A.  All it needs is 6.25GHz.   Links A-B and B-C 
don’t support this.   How will D know about this?
 
Hope this helps.    The discussion is around the need to advertise this 
info for each priority. 
Regards
Rajan

Cc: [email-masked]; 'CCAMP'; Iftekhar Hussain; 'Ramon Casellas'; 
'Zhangxian (Xian)'
 
Rajan, 

Thanks 
Qilei 

收件人
"[email-masked]" <[email-masked]>, "'Zhangxian (Xian)'" <
[email-masked]>, 'CCAMP' <[email-masked]>, 'Ramon Casellas' <
[email-masked]>, 
抄送
Iftekhar Hussain <[email-masked]> 
主题
Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Adrian, 

  
Thx 
Rajan 

Hi, 

  
  
I have three questions: 
  
Thanks, 
Adrian 

Hi, Rajan, 

Xian, 

  

  
Regards,
Xian 
  
Thx 
Rajan 

Hi, Rajan, all, 

  

  
  
Regards,
Xian 

Xian, all 

  
thx 
Rajan 
  
Hi, Rajan and all, 

  

  
Regards, 
Xian 

Xian, 

  
  
Thx 
Rajan 

Hi, Rajan, 

  

  
  
Cheers,
Xian 

Daniele, 

Thx 
Rajan   

Hi all, 

BR
Daniele 

Haomian, 

  
 
Thx 
Rajan 

Hi, Rajan, 

  
  0                   1                   2                   3 

In your proposal, 

  

Best wishes, 
Haomian 

Haomian, 

FWK doc Snip below: 
  
5.1.2.  Routing 

Thx 
Rajan 
  
From: Rajan Rao 
  
Haomian, 

-----Original Message-----
From: Zhenghaomian [mailto:[email-masked]] 
Sent: Monday, February 02, 2015 11:22 PM
To: Rajan Rao; Fatai Zhang
Cc: Khuzema Pithewan; Iftekhar Hussain
Subject: 答复: [CCAMP] 转发: I-D Action: 
  
Hi, Rajan, 

  

  

  
Best wishes, 
Haomian 
  
-----邮件原件----- 
发件人: Rajan Rao [mailto:[email-masked]] 
发送时间: 2014年12月18日 6:09 
收件人: Zhenghaomian; Fatai Zhang 
抄送: Khuzema Pithewan; Iftekhar Hussain 
主题: RE: [CCAMP] 转发: I-D Action: 
  
Haomian, 

  

Pl let me know. 
  
Thx 
Rajan 
  
-----Original Message----- 
From: Zhenghaomian [mailto:[email-masked]] 
Sent: Tuesday, December 16, 2014 5:15 PM 
To: Rajan Rao; Fatai Zhang 
Cc: Khuzema Pithewan 
Subject: 答复: [CCAMP] 转发: I-D Action: 
  
Hi, Rajan and Khuzema, 

  
Thanks. 
  
Best wishes, 
Haomian 
  
-----邮件原件----- 
发件人: Rajan Rao [mailto:[email-masked]] 
发送时间: 2014年12月17日 6:01 
收件人: Zhenghaomian; Fatai Zhang 
抄送: Khuzema Pithewan 
主题: RE: [CCAMP] 转发: I-D Action: 
  
Haomian, 

Thanks 
Rajan 
  
-----Original Message----- 
From: CCAMP [mailto:[email-masked]] On Behalf Of Zhenghaomian 
Sent: Tuesday, December 16, 2014 12:24 AM 
To: [email-masked] 
Subject: [CCAMP] 转发: I-D Action: 
  
Dear CCAMPers, 

Best wishes, 
  
-----邮件原件----- 

  
Abstract:

---

From: Rajan Rao <[email-masked]>
Date: Thu, 5 Mar 2015 01:47:20 +0000

Ramon,

It is a matter of how much finer control you want to provide in your network.   Don’t you think having  [Min, Max & Available bandwidth] per priority in one place gives a better control of resources?   Think of a network with  mix of C.S.  I can segregate the spectrum whichever way I want with the above 3 parameters.   This was the intent in our draft.

I am fine if WG wants to use RFC4203 as precedence and move on without priority for Minimum LSP bandwidth field.  We can jump to Adrian’s questions to see if there is any interest to pursue generalization.

Thx
Rajan

From: Ramon Casellas [mailto:[email-masked]]
Sent: Wednesday, March 04, 2015 1:30 AM
To: Rajan Rao; [email-masked]; 'Zhangxian (Xian)'; 'CCAMP'
Cc: Iftekhar Hussain
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

“…..an LSP at priority

Rajan, all

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 5 Mar 2015 03:20:01 +0000

Hi Qilei and Rajan,

I think Qilei meant that the example Rajan gave is nothing with Min LSP BW *per Priority*, :)

To address the example (potential compatible issue and might *Never* happen according to the LS from ITU-T SG15)  from Rajan, I think only one simple flag (if needed in the future) to be added is sufficient.

Best Regards

Fatai

From: CCAMP [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, March 05, 2015 9:07 AM
To: Rajan Rao
Cc: 'CCAMP'; Iftekhar Hussain
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Rajan,

Sorry about this.  What I really wanted to express is how to use the Min LSP BW for each priority. Just from my opinion, it will be necessary to advertise the Min LSP BW priority info as long as you point out we SHOULD use it somewhere.

As this thread is talking about this, I think maybe an example would help understanding.

Thanks
Qilei

2015-03-05 04:55

收件人

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,

抄送

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, 'CCAMP' <[email-masked]<mailto:[email-masked]>>, Iftekhar Hussain <[email-masked]<mailto:[email-masked]>>, 'Ramon Casellas' <[email-masked]<mailto:[email-masked]>>, "'Zhangxian (Xian)'" <[email-masked]<mailto:[email-masked]>>

主题

Qilei,

A-----B------C

A—B---C---D

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, March 04, 2015 1:12 AM
To: Rajan Rao
Cc: [email-masked]<mailto:[email-masked]>; 'CCAMP'; Iftekhar Hussain; 'Ramon Casellas'; 'Zhangxian (Xian)'
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Rajan,

Thanks
Qilei

2015-03-04 09:11

收件人

抄送

主题

Adrian,

Thx
Rajan

Hi,

I have three questions:

Thanks,
Adrian

Hi, Rajan,

Xian,

Regards,
Xian

Thx
Rajan

Hi, Rajan, all,

Regards,
Xian

Xian, all

thx
Rajan

Hi, Rajan and all,

Regards,
Xian

Xian,

Thx
Rajan

Hi, Rajan,

Cheers,
Xian

Daniele,

Thx
Rajan

Hi all,

BR
Daniele

Haomian,

Thx
Rajan

Hi, Rajan,

 0                   1                   2                   3

In your proposal,

Best wishes,
Haomian

Haomian,

FWK doc Snip below:

5.1.2.  Routing

Thx
Rajan

From: Rajan Rao

Haomian,

-----Original Message-----
From: Zhenghaomian [mailto:[email-masked]]
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,

Best wishes,
Haomian

-----邮件原件-----
发件人: Rajan Rao [mailto:[email-masked]]
发送时间: 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,

Pl let me know.

Thx
Rajan

-----Original Message-----
From: Zhenghaomian [mailto:[email-masked]]
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.

Best wishes,
Haomian

-----邮件原件-----
发件人: Rajan Rao [mailto:[email-masked]]
发送时间: 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,

Thanks
Rajan

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Zhenghaomian
Sent: Tuesday, December 16, 2014 12:24 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [CCAMP] 转发: I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Dear CCAMPers,

Best wishes,

-----邮件原件-----
发件人: CCAMP [mailto:[email-masked]] 代表 [email-masked]<mailto:[email-masked]>
发送时间: 2014年12月16日 16:16
收件人: [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Abstract:

---

From: Rajan Rao <[email-masked]>
Date: Thu, 5 Mar 2015 16:46:36 +0000

Fatai, Qilei,

Pl ref to email I responded to Ramon.  You can construct numerous examples with the combination [Min, Max, Available BW](Pn). See if it makes sense.

Thx
Rajan

From: Fatai Zhang [mailto:[email-masked]]
Sent: Wednesday, March 04, 2015 7:20 PM
To: [email-masked]; Rajan Rao
Cc: 'CCAMP'; Iftekhar Hussain
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Hi Qilei and Rajan,

Best Regards

Fatai

From: CCAMP [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, March 05, 2015 9:07 AM
To: Rajan Rao
Cc: 'CCAMP'; Iftekhar Hussain
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Rajan,

Thanks
Qilei

2015-03-05 04:55

收件人

抄送

主题

Qilei,

A-----B------C

A—B---C---D

Rajan,

Thanks
Qilei

2015-03-04 09:11

收件人

抄送

主题

Adrian,

Thx
Rajan

Hi,

I have three questions:

Thanks,
Adrian

Hi, Rajan,

Xian,

Regards,
Xian

Thx
Rajan

Hi, Rajan, all,

Regards,
Xian

Xian, all

thx
Rajan

Hi, Rajan and all,

Regards,
Xian

Xian,

Thx
Rajan

Hi, Rajan,

Cheers,
Xian

Daniele,

Thx
Rajan

Hi all,

BR
Daniele

Haomian,

Thx
Rajan

Hi, Rajan,

 0                   1                   2                   3

In your proposal,

Best wishes,
Haomian

Haomian,

FWK doc Snip below:

5.1.2.  Routing

Thx
Rajan

From: Rajan Rao

Haomian,

-----Original Message-----
From: Zhenghaomian [mailto:[email-masked]]
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,

Best wishes,
Haomian

-----邮件原件-----
发件人: Rajan Rao [mailto:[email-masked]]
发送时间: 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,

Pl let me know.

Thx
Rajan

-----Original Message-----
From: Zhenghaomian [mailto:[email-masked]]
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.

Best wishes,
Haomian

-----邮件原件-----
发件人: Rajan Rao [mailto:[email-masked]]
发送时间: 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,

Thanks
Rajan

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Zhenghaomian
Sent: Tuesday, December 16, 2014 12:24 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [CCAMP] 转发: I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Dear CCAMPers,

Best wishes,

-----邮件原件-----
发件人: CCAMP [mailto:[email-masked]] 代表 [email-masked]<mailto:[email-masked]>
发送时间: 2014年12月16日 16:16
收件人: [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Abstract: