Subject: Re: [CCAMP] POLLING - draft-ietf-ccamp-flexible-grid-ospf-ext-02 - Encoding Options

From: "Zhangxian (Xian)" <[email-masked]>
Date: Mon, 3 Aug 2015 03:10:37 +0000

Hi, Ramon, All,

For the poll,  I support Option 5: b) and c).  The reason behind c) is the same as what Ramon stated below. If allowing to use label to describe (un)available frequency slots (this point is debatable and mentioned below by Ramon), a) and b) are alike and I think b) can do a better job.

Having said this, I can live with the proposal Ramon put forward if that is what most of you would like to support.

My reply to some of the points Ramon raised below:

Regards,
Xian

From: CCAMP [mailto:[email-masked]] On Behalf Of Ramon Casellas
Sent: 2015年7月27日 17:58
To: [email-masked]
Subject: Re: [CCAMP] POLLING - draft-ietf-ccamp-flexible-grid-ospf-ext-02 - Encoding Options

El 27/07/2015 a las 11:14, Daniele Ceccarelli escribió:
Working group,

at the meeting in Prague we received a comment on the high number of existing options for “available resources” encoding in OSPF for flexi-grid.
The draft actually supports (in line with the WSON encoding) three methods:

a)      Inclusive/Exclusive label ranges

b)      Inclusive/Exclusive label Lists

c)      Bitmap label set

What we’d like to hear from the working group is if the worry for too many alternatives is shared and, if so, which ones are the preferred.
Please choose one of the following options and say why:

Option 1: a) only
Option 2: b) only
Option 3: c) only
Option 4: a)+b)+c) (i.e. keep the draft as it is)
Option 5: any combination of a),b),c). If you choose 5 please say which options you want to keep and which ones to drop.

Hi Daniele, all,

My personal preference is 5, including a) and c) . I would not object to other options  (including 4, deferring the choice as usual to the actual implementors to select what they want to implement).

Note that, as stated in the past and my main concern, the term "label" is IMHO a bit misleading, and that (mainly) a) and c) are actually referring to Nominal Central Frequencies (NCFs):  a bitmap encodes the status of the NCFs, not the "labels" themselves and when considering a "range" we are referring to the start and end as "NCFs", not start and end "labels" --  that is, no m --.

[Xian]: Point taken.  My understanding is that you are ok with the method we current taking, i.e., inheriting the methods from WSON. But you would like to see more explanation of the text? Is that correct? If so, let’s work on this together after the poll is closed, to make sure we make it clear in the draft.

Reasons:

- ranges are a straightforward way to disseminate which frequency slots that are "available", by giving the (start and end) NCFs, and being able to encode including "frequency slots" (holes) that would require 0.5 values of n and m
Range R1: [-1, 2]
   -9 -8 -7 -6 -5 -4 -3 -2 -1 0  1  2  3  4  5  6  7  8  9 10  11
   ...+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--...
                           |--------|

- (label) lists are verbose, although useful when the spectrum is very fragmented, a bitmap encoding may be fine too (I think they are currently in the draft for completeness).  In this case we could use label lists to describe "availbale frequency slots" but requiring values of 0.5 to cover all cases. I would like to drop it not to have options that use either "full labels" and other options that use "NCFs".

[Xian]: agreed. Actually, if we allow list to describe available frequency slots instead of describing NCFs (which I see you do not like, :)), then the list is almost the same as range and it can be better, IMHO.  As for the issue of 0.5 value, I think exclusive list would help in this case.

- Bitmap encoding is an efficient way to describe the status of the link and the way we have currently implemented. It needs to be clear what happens "at the edge": Assuming the link "total spectrum" starts at n=0 and if I chose n=0 as the base NCF, setting n=0 bit to 1 does not mean that it can be used as the allocated NCF.

[Xian]: Currently in the draft, we use the first NCF that can be allocated to request of m=1 as the base.  Since you mentioned, I think we should also make it clear in the next revision of this draft. My prefer is following the method mentioned in the current draft. Is that ok with you?

Regards,
Xian

It may be worth mentioning that we use _inclusive_ variants exclusively (sorry for the pun!)

Thanks and best regards,
Ramon

---

From: Zhenghaomian <[email-masked]>
Date: Tue, 11 Aug 2015 09:34:28 +0000

Hi, Daniele and CCAMPers,

As an author, I would like to keep the draft as it is, or alternatively speaking, keep it consistent with [RFC7579] (previous [GEN-ENCODE]) for label set field description, even if this is a new defined TLV.

I am interested in, if any implementation already support 3 methods as defined in [RFC7579], how much additional effort is needed to support 3 methods in this draft? If not much, I suggest we keep them all.

There won’t be inter-op problem as long as standardized.

Best wishes,
Haomian

发件人: CCAMP [mailto:[email-masked]] 代表 Daniele Ceccarelli
发送时间: 2015年7月27日 17:14
收件人: CCAMP ([email-masked])
主题: [CCAMP] POLLING - draft-ietf-ccamp-flexible-grid-ospf-ext-02 - Encoding Options

Working group,

c)       Bitmap label set

Option 1: a) only
Option 2: b) only
Option 3: c) only

Thanks,
Daniele

---

From: Julien Meuric <[email-masked]>
Date: Tue, 11 Aug 2015 14:32:13 +0200

Hi Haomian,

If the assertion below was true, I would be happy to agree with you. 
However, I am afraid you are wrong; therefore I fully support the 
attempt in progress to reduce the number of encoding options.
In this regards, I would vote for "c) only", stressing that the effort 
should be put on including the clarification suggested by Ramon into the 
draft.

Regards,

Julien

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 12 Aug 2015 00:32:14 +0200

Bonjour Julien,

I fully agree with your assessment.

I will also vote for "c) only".

Best regards, Huub.

=============
> should be put on including the clarification suggested by Ramon into 
> the draft.
>
> Regards,
>
> Julien
>
>
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

-- 
*****************************************************************
               请记住，你是独一无二的，就像其他每一个人一样