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

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 27 Jul 2015 09:14:08 +0000

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.

Thanks,
Daniele

---

From: Ramon Casellas <[email-masked]>
Date: Mon, 27 Jul 2015 11:57:40 +0200

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

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

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

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

Thanks and best regards,
Ramon

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 27 Jul 2015 14:23:51 +0000

Hi Ramon,

Thanks a lot for answering the polling but most of all for the valid comments. If the polling will lead to a change in the draft they'll be considered in the new version, otherwise threated as (pre-)last call comments.

Thanks
Daniele

From: CCAMP [mailto:[email-masked]] On Behalf Of Ramon Casellas
Sent: lunedì 27 luglio 2015 11:58
To: [email-masked]
Subject: Re: [CCAMP] POLLING - draft-ietf-ccamp-flexible-grid-ospf-ext-02 - Encoding Options

c)       Bitmap label set

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

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

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

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

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

Thanks and best regards,
Ramon

---

From: Dieter Beller <[email-masked]>
Date: Mon, 27 Jul 2015 18:18:10 +0200

Hi Ramon, Daniele, all,

the reason why we were discussing this last week during the CCAMP
session is that if multiple options are defined how the available
spectrum

can be advertised in a flex grid WDM network, an implementation
needs to support all of these options because you don't know which
option

a neighboring instance is using. And: the more options, the more
interoperability issues may occur among different implementations.
So, a

standard should always try to minimize the number of different options
that can be used for achieving the same thing.

Thanks,

Dieter

On 27.07.2015 16:23, Daniele Ceccarelli
wrote:

Hi Ramon,

Thanks a lot
for answering the polling but most of all for the valid
comments. If the polling will lead to a change in the draft
they’ll be considered in the new version, otherwise threated
as (pre-)last call comments.

Thanks

Daniele

From:
CCAMP [mailto:[email-masked]]
On Behalf Of Ramon Casellas

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

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

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

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

Thanks and best regards,

Ramon

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

---

From: Leeyoung <[email-masked]>
Date: Mon, 27 Jul 2015 21:30:39 +0000

Hi Daniele,

I support option 5 with a) and b) at the minimum. I can live without c) per se. Range still be a very useful way of encoding, in my option.

Thanks.
Young

From: CCAMP [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Monday, July 27, 2015 4:14 AM
To: CCAMP ([email-masked])
Subject: [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: Leeyoung <[email-masked]>
Date: Mon, 27 Jul 2015 21:31:12 +0000

Sorry I meant Option 5 with a) and c).

Young

From: Leeyoung
Sent: Monday, July 27, 2015 4:31 PM
To: 'Daniele Ceccarelli'; CCAMP ([email-masked])
Subject: RE: POLLING - draft-ietf-ccamp-flexible-grid-ospf-ext-02 - Encoding Options

Hi Daniele,

Thanks.
Young

Working group,

c)       Bitmap label set

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

Thanks,
Daniele

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 28 Jul 2015 07:37:37 +0000

Hi Dieter,

I understand your concern, this is why we're having this polling. I see you are in favor of reducing the number of options and the first replies seem to go towards the same direction.
If you could express your preferences on which option(s) to keep and which one(s) to drop it could be helpful for us to understand where the consensus is.

Thanks
Daniele

From: Dieter Beller [mailto:[email-masked]]
Sent: lunedì 27 luglio 2015 18:18
To: Daniele Ceccarelli; Ramon Casellas; [email-masked]
Subject: Re: [CCAMP] POLLING - draft-ietf-ccamp-flexible-grid-ospf-ext-02 - Encoding Options

Hi Ramon, Daniele, all,

the reason why we were discussing this last week during the CCAMP session is that if multiple options are defined how the available spectrum
can be advertised in a flex grid WDM network, an implementation needs to support all of these options because you don't know which option
a neighboring instance is using. And: the more options, the more interoperability issues may occur among different implementations. So, a
standard should always try to minimize the number of different options that can be used for achieving the same thing.

Thanks,
Dieter

On 27.07.2015 16:23, Daniele Ceccarelli wrote:
Hi Ramon,

Thanks
Daniele

From: CCAMP [mailto:[email-masked]] On Behalf Of Ramon Casellas
Sent: lunedì 27 luglio 2015 11:58
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] POLLING - draft-ietf-ccamp-flexible-grid-ospf-ext-02 - Encoding Options

c)       Bitmap label set

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

Hi Daniele, all,

Reasons:

Thanks and best regards,
Ramon

CCAMP mailing list

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

---

From: Dieter Beller <[email-masked]>
Date: Tue, 28 Jul 2015 15:36:01 +0200

Hi Daniele, all,

here is my vote:  Option 3: c) only (bitmap label set)

Why: a single encoding is preferred and the encoding is simple and
pretty straight forward. The other 2 encoding options are only
sometimes more

compact in terms of OSPF-TE message size.

Thanks,

Dieter

On 28.07.2015 09:37, Daniele Ceccarelli
wrote:

Hi Dieter,

I understand
your concern, this is why we’re having this polling. I see
you are in favor of reducing the number of options and the
first replies seem to go towards the same direction.

If you could
express your preferences on which option(s) to keep and
which one(s) to drop it could be helpful for us to
understand where the consensus is.

Thanks

Daniele

From:
Dieter Beller
[mailto:[email-masked]]

To: Daniele Ceccarelli; Ramon Casellas;
[email-masked]

Hi
Ramon, Daniele, all,

the reason why we were discussing this last week during
the CCAMP session is that if multiple options are defined
how the available spectrum

can be advertised in a flex grid WDM network, an
implementation needs to support all of these options
because you don't know which option

a neighboring instance is using. And: the more options,
the more interoperability issues may occur among different
implementations. So, a

standard should always try to minimize the number of
different options that can be used for achieving the same
thing.

Thanks,

Dieter

Hi Ramon,

Thanks a
lot for answering the polling but most of all for the
valid comments. If the polling will lead to a change in
the draft they’ll be considered in the new version,
otherwise threated as (pre-)last call comments.

Thanks

Daniele

From:

To: [email-masked]

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

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

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

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

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

Thanks and best regards,

Ramon

CCAMP mailing list

[email-masked]

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Tue, 28 Jul 2015 17:30:55 +0000

Hi Ramon,

could you map your last sentence about "bitmap" usage on the example you reported here:

Not clear for me what you mean referring bitmap usage .
Thanks

Sergio

c)      Bitmap label set

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

Hi Daniele, all,

Reasons:

Thanks and best regards,
Ramon

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 29 Jul 2015 09:22:55 +0200

El 28/07/2015 a las 19:30, BELOTTI, SERGIO (SERGIO) escribió:
>
> Hi Ramon,
>
> could you map your last sentence about “bitmap” usage on the example 
> you reported here:
>
Dear Sergio, all

My comment was more in the sense of trying to clarify the use of bitmap. 
Consider that we have, for example, the following (sorry if the mail is 
trivial or stating well known things):

A) The "usable" spectrum in a link is characterized by, say, start ncf 
n=0, end ncf=31 (32 NFCs, one bitmap "word") to simplify. We use 
systematically "base" n as n0 in all bitmap encodings. AFAIK, the draft 
allows you to start disseminating starting from an arbitrary base n, but 
since we manage a few hundreds of NCFs, our implementation always starts 
at the lowest n for the link.

B) A priori, one could naively expect to have a 32 bit bitmap having all 
'1' since it there are no LSPs...

C) However, what does "free" or "available" for a NCF mean? IMHO, it is 
not clearly defined. A possible interpretation /is to announce it as 
free if that you can allocate a minimum FS with m=1 using that "n" as 
the FS NCF/. This means that, in our case, both n=n0 and n=n31 should 
not be announced as '1', since any FS would overflow/underflow the 
spectrum available in the link. Alternatively, one could chose to 
disseminate them as free assuming that the RSA algorithm would take into 
account edge conditions,but this means that the path computation (assume 
a PCE) would need to know the start and end of the link if we do not 
systematically disseminate all NCFs of the link(in other words, if a 
second LSA disseminates a bitmap starting with n base = n3, we would 
need to know that n3 is not the lowest n for the link.

We would need to go from this:

0  1  2  3  4  5  6  ...   31
+--+--+--+--+--+--+--+--+--+
1  1  1  1  1  1  1  1  1  1

to this; this means agreeing on putting the "ends" at 0, but seems 
counter-intuitive wrt B) In your specific question, the NCFs 1 and 2 
would be "1"

0  1  2  3  4  5  6  ...   31
+--+--+--+--+--+--+--+--+--+
0  1  1  1  1  1  1  1  1 0

If we want to set up an LSP m=3 the PCE needs to find an n (ni) such 
that all n from ni - m + 1 to ni + m -1 is "1". In this case, using 
First fit, ni=3 and all NCFs up to 6 change to 0
0  1  2  3  4  5  6  ...   31
+--+--+--+--+--+--+--+--+--+
0 0 0 0 0 00  1  1 0

To conclude, in our case we always disseminate the whole supported NCFs 
in the bitmap, so the PCE knows the "edges" and it does not really 
matter if n0=0 or 1 or n31 is0 or 1. we may need to clarify this in in 
draft, perhaps?

Thanks
R

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 29 Jul 2015 12:36:49 +0000

Dear Ramon,

thanks, your explanation of the problem is important anyway (trivial or not) . I think that a clarification on the draft would avoid possible misunderstanding in the usage of bitmap.

See in line for some comment.

Thanks
sergio

From: Ramon Casellas [mailto:[email-masked]]
Sent: mercoledì 29 luglio 2015 09:23
To: BELOTTI, SERGIO (SERGIO)
Cc: [email-masked]
Subject: Re: [CCAMP] POLLING - draft-ietf-ccamp-flexible-grid-ospf-ext-02 - Encoding Options

Dear Sergio, all

My comment was more in the sense of trying to clarify the use of bitmap. Consider that we have, for example, the following (sorry if the mail is trivial or stating well known things):

A) The "usable" spectrum in a link is characterized by, say, start ncf n=0, end ncf=31 (32 NFCs, one bitmap "word") to simplify. We use systematically "base" n as n0 in all bitmap encodings. AFAIK, the draft allows you to start disseminating starting from an arbitrary base n, but since we manage a few hundreds of NCFs, our implementation always starts at the lowest n for the link.

B) A priori, one could naively expect to have a 32 bit bitmap having all '1' since it there are no LSPs...

C) However, what does "free" or "available" for a NCF mean? IMHO, it is not clearly defined. A possible interpretation is to announce it as free if that you can allocate a minimum FS with m=1 using that "n" as the FS NCF. This means that, in our case, both n=n0 and n=n31 should not be announced as '1', since any FS would overflow/underflow the spectrum available in the link. Alternatively, one could chose to disseminate them as free assuming that the RSA algorithm would take into account edge conditions, but this means that the path computation (assume a PCE) would need to know the start and end of the link if we do not systematically disseminate all NCFs of the link (in other words, if a second LSA disseminates a bitmap starting with n base = n3, we would need to know that n3 is not the lowest n for the link.

0  1  2  3  4  5  6  ...   31

to this; this means agreeing on putting the "ends" at 0, but seems counter-intuitive wrt B) In your specific question, the NCFs 1 and 2 would be "1"

0  1  2  3  4  5  6  ...   31

If we want to set up an LSP m=3 the PCE needs to find an n (ni) such that all n from ni - m + 1 to ni + m - 1 is "1". In this case, using First fit, ni=3 and all NCFs up to 6 change to 0
0  1  2  3  4  5  6  ...   31
+--+--+--+--+--+--+--+--+--+
0  0  0  0  0  0  0  1  1  0
SB> following your thoughts about the spectrum at the edge and if you consider m=3 , that means if SGW is 12.5 Ghz.  6.25 is the NCG , so SW is 12.5x3 --> 6.25x6 , so the first 6 n is 0. Is this your reasoning?
BTW also around n31 it would be some 0 .

To conclude, in our case we always disseminate the whole supported NCFs in the bitmap, so the PCE knows the "edges" and it does not really matter if n0=0 or 1 or n31 is 0 or 1. we may need to clarify this in in draft, perhaps

Thanks
R

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 29 Jul 2015 14:44:01 +0200

El 29/07/2015 a las 14:36, BELOTTI, SERGIO (SERGIO) escribió:
(snip)
> that all n from ni - m + 1 to ni + m - 1 is "1". In this case, using 
> SB> following your thoughts about the spectrum at the edge and if you 
> consider m=3 , that means if SGW is 12.5 Ghz.  6.25 is the NCG , so SW 
> is 12.5x3 --> 6.25x6 , so the first 6 n is 0. Is this your reasoning?
>
Ramon> yes, I am assuming SWG=12.5 GHz, ncf gran. 6.25Ghz (the only ones 
as per itu-t and in the fw). The allocated slot is shown below, the 
first "available" ncf would be n=7 (that allows another FS with m=1). 
Not sure what you mean about n=31 (still at 0). Following my previous 
mail, if now we wanted to disseminate starting with base n=6 it would 
also be 0111111  (as if we shifted the start NCF for the available range)

0 1  2  3  4  5  6  ...   31
+-----------------+
|                 |
+--+--+--X--+--+--+--+--+--+
0  0  0  0  0  0  0  1  1  0

Thanks

R.

---

From: Dieter Beller <[email-masked]>
Date: Wed, 29 Jul 2015 18:15:02 +0200

Hi Ramon, all,

here are my thoughts how the Bitmap could be defined and
interpreted (probably we are on the same page):

As far as the available spectrum is concerned you need to
advertise whether a 6.25GHz frequency slot is available or is not
available.

Such a slot is the spectrum between 2 NCFs and you may say that
the lower edge frequency (lower NCF) uniquely identifies the slot

corresponding also to a n as defined in G.694.1: NCF(n) = 193.1THz
+ n × 0.00625THz

Now, we need to define how the bitmap is anchored on the frequency
grid. Looking at RFC7579, you find:

2.6.3. Bitmap Label Set

For bitmap sets (Action = 4), the label set format is:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Num Labels | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base Label |
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bitmap Word #1 (Lowest numerical labels) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bitmap Word #N (Highest numerical labels) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In this case, Num Labels tells us the number of labels represented by
the bitmap. Each bit in the bitmap represents a particular label
with a value of 1/0 indicating whether or not the label is in the
set. Bit position zero represents the lowest label and corresponds
to the base label, while each succeeding bit position represents the
next label logically above the previous.

The size of the bitmap is Num Labels bits, but the bitmap is padded
out to a full multiple of 32 bits so that the field is a multiple of
four bytes. Bits that do not represent labels SHOULD be set to zero
and MUST be ignored.

If the Base Label field is providing the lower
edge frequency of the lowest 6.25GHz slot or the corresponding n
(see NCF formula), it is clear how

to interpret the Bitmap:

Bit position zero represents the lowest label and corresponds to the base label, while each succeeding bit
position represents the next label logically above the previous.

As the channel width of a modulated carrier has to be a multiple
of 12.5GHz, you always have to allocate an even number of 6,25GHz
slots that

are symmetrical w.r.t. the NCF of the carrier. The NCFs themselves
are not relevant as far as the available spectrum is concerned.
They are just

the edges of the 6.25GHz slots.

So, it is well possible to unambiguously describe the available
spectrum in an OSPF LSA using the Bitmap option as described above. This
OSPF

LSA information can then be converted into any implementation
specific internal representation suitable for path computation.
That's of course

outside the scope of a standard.

Thanks,

Dieter

On 29.07.2015 14:44, Ramon Casellas
wrote:

El 29/07/2015 a las 14:36, BELOTTI,
SERGIO (SERGIO) escribió:

(snip)

0  1  2  3  4  5  6  ...   31

0  1  1  1  1  1  1  1  1  0

If we want to set up an LSP m=3 the PCE needs to find
an n (ni) such that all n from ni - m + 1 to ni + m - 1
is "1". In this case, using First fit, ni=3 and all NCFs
up to 6 change to 0

0  1  2  3  4  5  6  ...   31

0  0  0  0  0  0  0  1  1  0

SB> following your
thoughts about the spectrum at the edge and if you
consider m=3 , that means if SGW is 12.5 Ghz.  6.25 is the
NCG , so SW is 12.5x3 --> 6.25x6 , so the first 6 n is
0. Is this your reasoning?

BTW also around n31 it
would be some 0 .

Ramon> yes, I am assuming SWG=12.5 GHz, ncf gran. 6.25Ghz (the
only ones as per itu-t and in the fw). The allocated slot is shown
below, the first "available" ncf would be n=7 (that allows another
FS with m=1). Not sure what you mean about n=31 (still at 0).
Following my previous mail, if now we wanted to disseminate
starting with base n=6 it would also be 0111111  (as if we shifted
the start NCF for the available range)

0

1  2  3  4  5  6  ...   31

+-----------------+

|                 |

0  0  0  0  0  0  0  1  1  0

Thanks

R.

--

DIETER
BELLER

ALCATEL-LUCENT
DEUTSCHLAND AG

PROJECT MANAGER ASON/GMPLS CONTROL PLANE

IP ROUTING AND TRANSPORT BL

IP TRANSPORT BU

Lorenzstrasse 10

70435 Stuttgart, Germany

Phone: +49 711 821 43125

Mobil: +49 175 7266874

[email-masked]

Alcatel-Lucent
Deutschland AG

Domicile of the Company: Stuttgart · Local Court Stuttgart HRB
4026

Chairman of the Supervisory Board: Michael Oppenhoff

Board of Management: Wilhelm Dresselhaus (Chairman) · Hans-Jörg
Daub · Ralf Niederberger

This e-mail and its attachments, if any, may contain
confidential information.

If you have received this e-mail in error, please notify us and
delete or destroy the e-mail and its attachments, if any,
immediately.

If you have received this e-mail in error, you must not forward
or make use of the e-mail and its attachments, if any.

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 29 Jul 2015 19:32:55 +0200

El 29/07/2015 a las 18:15, Dieter Beller escribió:
> Hi Ramon, all,
>
>
> As far as the available spectrum is concerned you need to advertise 
> whether a 6.25GHz frequency slot is available or is not available.
Hi Dieter, all

(snip) Agreed, at the end, it is just a matter of clearly defining what 
it means that a given NCF "n" is "available" (it can be that a FS of m=1 
can be allocated or, as you say, that the portion of spectrum of 6.25GHz 
at the "left" or "at the right" is available or any other equivalent 
definition). Once this is agreed, the encoding is relatively 
straightforward. Whether it is "both sides" or "just one side" will 
determine, on a per link basis, the base "n" and the rest of NCFs.

Ex: if a link has a usable spectrum between n=0 and n=7, if we use i) "a 
NCF bit is 1 if an FS of m=1 can be allocated around it" or ii) "a 
NCFbit  is 1 if the right 6.25 GHz portion is available" the encoding is 
different:

|<----------->|
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+
0 1 1 1 1 1 1 0 i)
1 1 1 1 1 1 1 0 ii)

We agree that, if the semantic is known, the spectrum allocation is the 
same since the allocation needs to allocate in slots multiple of 12.5GHz 
around the chosen n.
IMHO I do believe the draft could clarify it.

Thanks
R.